WHAT IS TEST-DRIVEN DEVELOPMENT?
Test-Driven Development (TDD) is a style of
development where:
you maintain an exhaustive suite of Programmer
Tests,
no code goes into production unless it has
associated tests,
you write the tests first,
the tests determine what code you need to
write.
Let's look at each of these in turn.
Maintain an exhaustive suite of
Programmer Tests
You have Programmer Tests to test that your
classes exhibit the proper behavior. Programmer Tests are written
by the developer who writes the code being tested. They're called
Programmer Tests because although they are similar to unit tests,
they are written for a different reason. Unit tests are written to
test that the code you've written works. Programmer Tests are
written to define what it means for the code to work. Finally,
they're called Programmer Tests to
differentiate them from the tests that the Customer writes (called, logically
enough, Customer Tests) to test
that the system behaves as required form the point of view of a
user.
Using Test-Driven Development implies, in
theory, that you have an exhaustive test suite. This is because
there is no code unless there is a test that requires it in order
to pass. You write the test, then (and not until then) write the
code that is tested by the test. There should be no code in the
system which was not written in response to a test. Hence, the test
suite is, by definition, exhaustive.
No code goes into production unless it
has associated tests
One of eXtreme Programming's tenets is that a
feature does not exist until there is a suite of tests to go with
it. The reason for this is that everything in the system has to be
testable as part of the safety net that gives you confidence and
courage. Confidence that all the code tests clean gives you the
courage (not to mention the simple ability) to refactor and
integrate. How can you possibly make changes to the code without
some way to confidently tell whether you have broken the previous
behavior? How can you integrate if you don't have a suite of tests
that will immediately (or at least in a short time) tell you if you
have inadvertently broken some other part of the code?
Write the tests first
Now we're getting eXtreme. What do I mean by
write the tests first? I mean that
when you have a task to do (i.e., some bit of functionality to
implement) you write code that will test that the functionality
works as required before you implement the functionality
itself.
Furthermore, you write a little bit of test,
followed by just enough code to make that test pass, then a bit
more test, and a bit more code, test, code, test, code, etc.
Tests determine what code you need to
write
By writing only the code required to pass
the latest test, you are putting a limit on the code you will
write. You write only enough to pass the test, no more. That means that you do the simplest thing that could possibly
work. I think an example is in order. Let's say you are
working on a list class. The logical place to start is with the
behavior of an empty list (it makes sense to start with the basis,
or simplest, case). So you write the test:
public void testEmptyList() {
MovieList emptyList =newMovieList();
assertEquals("Empty list should have size of 0", 0, emptyList.size());
}
To pass this test we need a MovieList
class that has a size() method.
When you are working this way, you want to work
in small increments. . . some-times increments that seem
ridiculously small. When you grasp the significance of this, you
will be on your way to mastering TDD. Later we'll explore the
important and sometimes unexpected benefits and side effects of
testing and coding in tiny increments.
| 
No comments:
Post a Comment