The document discusses taking a test drive of a new product from Fuzzy Aliens Limited. It includes the author's name and company but does not provide any other relevant details.
8. Episode 1 Summary
Software should satisfy the users’ needs
Testing demonstrates that this is true
Unit testing can be done by the developer
Cheap
Well-situated
Test-Driven Development is a design practice
9. This week, on VTM…
- (void)testBlah {
STAssertTrue(thisThing.state == NSOnState,
@”Is this thing on?”);
}
10. This week, on VTM…
OC_TEST_CASE(“General/IsOn”, “Is this thing on?”) {
REQUIRE(thisThing.state == NSOnState);
}
https://github.com/philsquared/Catch
@phil_nash
26. A test is not a unit test if:
It talks to the database Michael Feathers, idealized unit
test
It communicates across the network
It touches the file system
It can't run at the same time as any of your other unit tests
You have to do special things to your environment
34. Recipe: NSNotificationCenter
Actually talking about Singletons in general
Rule #1 of Singletons is don’t use Singletons
Cocoa Touch doesn’t give us much choice
Remember, a singleton is a global in sheep’s clothing.
35. Recipe: NSNotificationCenter
- (void)watchForThingsHappening {
[[NSNotificationCenter defaultCenter]
addObserver: self
selector: @selector(workDidFinish:)
name: WorkDidFinishNotification
object: worker];
}
OC_TEST_CASE("ViewController/WorkerFinished", "Ensure we
know when the work's done") {
[controller watchForThingsHappening];
REQUIRE(/*???*/);
}
39. Conclusions
TDD implies a particular approach to writing APIs
Certain patterns support this approach way
40. Conclusions
TDD implies a particular approach to writing APIs
Certain patterns support this approach way
The patterns you’ve seen today work well with TDD and with the
Cocoa Touch SDK
#16:The idea is to provide a set of recipes that you can use in testing iPhone apps. Note that I won’t talk about the automated UI testing Instrument - that’s not TDD or unit testing.\n
#17:The idea is to provide a set of recipes that you can use in testing iPhone apps. Note that I won’t talk about the automated UI testing Instrument - that’s not TDD or unit testing.\n
#18:The idea is to provide a set of recipes that you can use in testing iPhone apps. Note that I won’t talk about the automated UI testing Instrument - that’s not TDD or unit testing.\n
#19:The idea is to provide a set of recipes that you can use in testing iPhone apps. Note that I won’t talk about the automated UI testing Instrument - that’s not TDD or unit testing.\n
#20:The idea is to provide a set of recipes that you can use in testing iPhone apps. Note that I won’t talk about the automated UI testing Instrument - that’s not TDD or unit testing.\n
#21:I’ve previously said that NeXT should never have allowed ObjC code that didn’t follow MVC to compile. I still stand by that.\n
#22:The most common thing I get wrong with outlets is to not set them in the NIB. My strategy for dealing with this is to assert that the outlet is not nil so the app will die if I forget.\n\n
#23:There’s no problem with programmatically creating views in test code, you don’t even need to provide a frame if not necessary. That avoids relying on the XIB in test cases, which is environmental data. For complicated views, it may be easier to fake them.\n
#24:The arrow shows increasing “tell, don’t ask”-ness. If you use the first action type, the action method has to find out what it needs to know. That means introspection, which is harder to test than explicit demand (“no, use _this_ button”).\n
#30:The Builder pattern allows you to decouple the construction of objects from their use. This is automatic to some extent in ObjC because of the way Class objects work, but in this case it’s good to have an object that returns a class of a type you define.\n
#33:It’s also important to look at what a unit test is not. How to avoid I/O -> fake/mock objects. In-memory CoreData. Textcast has 212 unit tests that run in 0.6 seconds.\n\n“Tests that do these things aren't bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes”\n
#35:Note that this does violate the “don’t depend on data” principle, but Core Data is useless without a MOM so you need to do this. The real deal is the in-memory store. Note that an error is ignored in -tearDown, but if you have that error then you should write a test anyway. As I did to ensure that the store is correctly set up.\n
#36:Note that this does violate the “don’t depend on data” principle, but Core Data is useless without a MOM so you need to do this. The real deal is the in-memory store. Note that an error is ignored in -tearDown, but if you have that error then you should write a test anyway. As I did to ensure that the store is correctly set up.\n
#37:Note that this does violate the “don’t depend on data” principle, but Core Data is useless without a MOM so you need to do this. The real deal is the in-memory store. Note that an error is ignored in -tearDown, but if you have that error then you should write a test anyway. As I did to ensure that the store is correctly set up.\n
#38:Note that this does violate the “don’t depend on data” principle, but Core Data is useless without a MOM so you need to do this. The real deal is the in-memory store. Note that an error is ignored in -tearDown, but if you have that error then you should write a test anyway. As I did to ensure that the store is correctly set up.\n
#39:NSNotificationCenter is a good example of a singleton that app code often makes use of. Singletons encourage “ask, don’t tell” because it’s easy to grab the shared instance from anywhere. The problem is that this means relying on the code’s environment, which is bad. Let’s try and get out of that.\n
#40:NSNotificationCenter is a good example of a singleton that app code often makes use of. Singletons encourage “ask, don’t tell” because it’s easy to grab the shared instance from anywhere. The problem is that this means relying on the code’s environment, which is bad. Let’s try and get out of that.\n
#41:NSNotificationCenter is a good example of a singleton that app code often makes use of. Singletons encourage “ask, don’t tell” because it’s easy to grab the shared instance from anywhere. The problem is that this means relying on the code’s environment, which is bad. Let’s try and get out of that.\n
#43:This is the best solution. Another approach is to swizzle the -defaultCenter method to return your mock. That’s a bit dangerous: though test code isn’t production code so if it works for you, do it. Beware the pitfalls though.\n