 Unit tests are one of the
corner stones of Extreme Programming (XP). But unit tests XP style is a little different. First you should create
or download a unit test framework to be able to create automated unit tests
suites. Second you should test all classes in the system. Trivial getter and setter methods are usually omitted.
And last you should try to create your tests first, before the code.
Unit tests are released
into the code repository along with the code they test. Code without tests may not be released. If a unit test
is discovered to be missing it must be created at that time.
The biggest resistance to
dedicating this amount of time to unit tests is a fast approaching deadline. But during the life of a project an
automated test can save you a hundred times the cost to create it by finding and guarding against bugs. The harder
the test is to write the more you need it because the greater your savings will be. Automated unit tests offer
a pay back far greater than the cost of creation.
Another common misconception
is that unit tests can be written in the last three months of |
the project. Unfortunately, without the unit tests development drags on and eats up those last three months and
then some. Even if the time is available good unit test suites take time to evolve. Discovering all the problems
that can occur takes time. In order to have a complete unit test suite when you need it you must begin creating
the tests today when you don't.
Unit tests enable collective
code ownership. When you create unit tests you guard your functionality from being accidentally harmed. Requiring
all code to pass all unit tests before it can be released ensures all functionality always works. Code ownership
is not required if all classes are guarded by unit tests.
Continued
on page 2 
|
