In this article, Jim Menard is going to describe testing frameworks and walk through the process of adding unit tests to CheckbooX.
Unit Testing with OCUnit
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I do not use this:
1) Write a test case for a single feature.
2) Run the test and watch it fail.
3) Write the code that implements the feature.
4) Make it work.
5) GOTO 1.
The reason why I do not use the above, is because it doesn’t work well. IMHO, it is stupid. Whomever wrote that was probably high on something, and it has spread mushrooms after the rain, but I do not believe that many people use it. It is like creating a crash test for a car, then you find out that the car doesn’t fit in the test facility because it is a semi-truck. It is better to write the code first and the tests later.
I do use this:
1) Write a large chunk of the application.
2) Write test suites that exercise everything written so far.
3) Fix the bugs found by the tests.
5) Write a few more tests; fix some more bugs.
6) Add new features.
7) Write tests for the new features.
GOTO 5.
Writing the code first, and the tests later is much better, because now you know what the code looks like and what to test for.
The test first approach is motivated by the idea that the tests are the first users of the code and that they define the requied functionality.
If you don’t like the approach fine, but don’t be so glib in your denigration of test first.
Where in your testing cycle is any mention of a sprecification? How do you find bugs in code with no specification of what it should really do? Knowing what you have coded and therefore knowing “what to test for” is only likely to reveal the problems you expect, isn’t it?