Typhoon Plugins?

[alexgarbarev]

Typhoon is growing up with new features and I hope it will be in future with same rate, but putting all features in one project can be bad idea. Because in this case Typhoon will be a kind of moster which can do everything.
So, Idea to split functionality into separated pods. One for Core, one for TestUtils(maybe), one for Configuration. Since TyphoonCore has a flexible architecture with postprocessors, definition enumerations we can organize seamless interaction between Core and Plugins

[jasperblues]

👍 Great! Except there was one similar framework for Java that ended up with just way too many modules. (Spring Social, Spring Integration, Spring Batch, Spring Webflow). . powerful, but so many damn options! (And not all of them were great like the original core). Especially considering you could instead just use . . . "Rails" (more monolithic, but maybe in a good way?).

So, while I agree, I'm also with the "Apple philosophy" - what's left out can be even more important that what goes in. . And I'm comfortable with the idea of removing features if we hit upon a new or better way of doing something (as we've been doing) . . . I think its better to move quickly, make mistakes, get feedback and improve, rather than sit on the side-line. This will bring everyone better value in the long run.

On Test Utils

It should really be called IntegrationTestUtils. It consists of:

• Asynch testing support
• TyphoonPatcher

Asynch Testing:

This when into Typhoon v1.0 because I wasn't happy with the options for doing integration and for testing asynchronous or threaded applications. The consensus at the time was:

• Use more mocks or other test doubles. Good. But we can't escape threads in iOS. And as DHH famously pointed out recently, sometimes integration testing gives you bigger bang for your buck.
• Use something like Kiwi/Cedar or expecta, which has asynchronous matchers. These are cool. But Kiwi is a whole framework in its own right, and to me IDE integration (eg, being able to run just one test at a time in AppCode) was more important than the BDD style, which you can still do to an extent with plain-old Sen/XCTest. . . and expecta didn't have fine-grained control over time-outs.

I wanted just asynch matching assertions without the baggage. (Someone else might want just this without the baggage of Typhoon! ;) )

TyphoonPatcher:

Integration Testing can give a good bang for your buck, but sometimes its difficult to get the system into the required state. Fortunately, dependency injection modularizes configuration, so we can easily patch out one component for another, in order to set up for a test scenario. . . this feature was designed with testing in mind, but could potentially be used elsewhere.

. . at the time I just threw it in with Typhoon because I had a lot of other stuff features to get done, and CocoaPods wasn't huge yet, so it was huge yet, so it was important to be able to build as one project.

Also there were some features planned (still pending), like supporting auto-wiring annotations for integration tests. So it would make sense to have a new module especially for these.

[jasperblues]

I agree to create a separate test utils module. (Depending on % of users requiring such features, we could also move it outside Typhoon). . .

. . . regarding Config, I'd be inclined to make it part of the Core Di container. . . its still strongly aligned with the concept of DI, which is about modularizing an application's config/assembly.

Though the planned config editing view controller - that could probably go in a separate module.

[fortinmike]

So, Idea to split functionality into separated pods. One for Core, one for TestUtils(maybe), one for Configuration.

Seems like a good candidate for CocoaPods Subspecs.

[jasperblues]

Let's create specific refactoring tickets to extract one or more modules when required.