Here are my notes on Graham Lee' unit testing presentation. Note: coming into this, I have heard of unit testing and have a general idea of what it means, but I have never seen it done. I presume it means to do an automated process of running a method with different data sets and checking that the answer is what you wanted each time. Probably, it includes boundary cases, but I don't know.
Software engineering goals: make money (sometimes)... By making something that the user wants. - meets their requirements, without being too expensive.
Testing isn't about finding bugs - it's about validating that your code does what it should., finding bugs is a secondary effect.
The earlier a bug is introduced, the more it costs if you find it late. Unit testing helps with the design and build aspects reducing errors.
Undirected unit testing - checking the minutiae of the program, the opposite side from external testing by somebody who doesn't know the program I.e., the user.
test driven development:
*black-box thinking for the developer.
*YAGNI you ain't gonna need it. Only write the code you need.
*Avoid regression bugs. Keep the tests around, so later code doesn't break earlier code without your knowledge.
*assists accurate planning
Find bugs before....
...your customers do.
Zune didn't know about leap year. Ah, they're incredibly rare.
TDD != [bullet silverColor]
you can't assume the developer understood the problem...or that the requirements didn't change, and it doesn't guarantee successful integration
Takes time to write tests, and you actually run them.
How TDD works: RED - GREEN - REFACTOR
What do I test? Anything within reason - time, environmental conditions (ie DBs, filesystem, network - not repeatable)
Evaluate risk - known buggy code, heavily used code, tricky problems
When do I test? At any change, plus before release.
Testable code: short classes with short methods, each with obvious effects, few & predictable side effects, with helper data passed in - not discovered, low "cyclomatic complexity" - don't need to test thousands of combinations.
This means the end of a @interface GodView:UIViewController
OCUnit and XCode3 or XCode4
GHUnit ... Better than OCUnit? (Does it run on the iPod, itself?-HH)
plug of kaleidoscope app?
Fakes and mocks? Fake is dummy input data, and mock is dummy local data, I think.... - HH
Recommends "refactoring: improving the design of existing code", "test-driven development"(Kent beck), "test-driven development: a practical guide", "xUnit test Patterns", et al
Iamleeg at the usual sites, twitter, etc.
Note: I know more than I did, but I still don't know enough that I am ready to go out and start unit testing. A lot of theory here, but I probably needed a more practical demonstration.
- Posted using BlogPress from my iPad
Saturday, October 16, 2010
Subscribe to:
Post Comments (Atom)
After my blog was posted, Graham Lee got in touch with me and sent me a link to a real-world example on his blog:
ReplyDeletehttp://tinyurl.com/2wtchfe
Glad you picked up on the blog post with the example. I was just coming here to link to it :). Great notes, thanks for publishing them. I've made the slides available at: http://www.slideshare.net/iamleeg/unit-testing-for-cocoa-developers
ReplyDeleteBTW regarding fakes and mocks, while there is a distinction (fakes are things that let you control a method's input, mocks let you see the method's output) I tend to lump them together as "things that let you see what's happening in a method".