 When you
create your tests first, before the code, you will find it much easier
and faster to create your code. The combined time it takes to create a
unit test and create some code to make it pass is about the same as
just coding it up straight away. But, if you already have the unit
tests you don't need to create them after the code saving you some time
now and lots later.
Creating
a unit test helps a developer to really consider what needs to be done.
Requirements are nailed down firmly by tests. There can be no
misunderstanding a specification written in the form of executable code.
You
also have immediate feedback while you work. It is often not clear when
a developer has finished all the necessary functionality. Scope creep
can occur as extensions and error conditions are considered. If we
create our unit tests first then we know when we are done; the unit
tests all run.
There
is also a benefit to system design. It is often very difficult to unit
test some software systems. These systems are typically built code
first and testing second, often by a different team entirely. By
creating tests first your design will be influenced by a desire to test
everything of value to your customer. Your design will reflect this by
being easier to test. |
There
is a rhythm to developing software unit test first. You create one test
to define some small aspect of the problem at hand. Then you create the
simplest code
that will make that test pass. Then you create a second test. Now you
add to the code you just created to make this new test pass, but no
more! Not until you have yet a third test. You continue until there is
nothing left to test. The coffee maker problem shows an example written in Java.
The
code you will create is simple and concise, implementing only the
features you wanted. Other developers can see how to use this new code
by browsing the tests. Input whose results are undefined will be
conspicuously absent from the test suite. 
   |
