HTML and CSS Reference
and generally making a mess of the process. This is the worst kind of situation to
be in—investing extra time in test-driven development, but because it is not being
done right we cannot really trust the outcome the way we are supposed to, and in
the worst case we will end up spending more time writing worse code. Smoothly
running tests are key.
The recommended approach is to run some form of autotest. Autotesting means
that tests are run every single time a file is saved. A small discrete indicator light
can tell us if tests are green, currently running, or red. Given that big monitors are
common these days, you may even allocate some screen real-estate for a permanent
test output window. This way we can speed up the process even more because we are
not actively running the tests. Running the tests is more of a job for the environment;
we only need to be involved when results are in. Keep in mind though that we still
need to inspect the results when tests are failing. However, as long as the tests are
green, we are free to hack voraciously away. Autotesting can be used this way to
speed up refactoring, in which we aren't expecting tests to fail (unless mistakes are
made). We'll discuss autotesting for both IDEs and the command line in Chapter 3,
Tools of the Trade.
In the introduction to this chapter we touched on some of the benefits that test-
driven development facilitates. In this section we will rehash some of them and
touch on a few others as well.
2.4.1 Code that Works
The strongest benefit of TDD is that it produces code that works. A basic line-by-
line unit test coverage goes a long way in ensuring the stability of a piece of code.
to test code on a wide range of browser/platform combinations. Because the tests
are written to address only a single concern at a time, bugs should be easy to discover
using the test suite, because the failing tests will point out which parts of the code
are not working.
2.4.2 Honoring the Single Responsibility Principle
Describing and developing specialized components in isolation makes it a lot eas-
ier to write code that is loosely coupled and that honors the single responsibility
principle. Unit tests written in TDD should never test a component's dependencies,
which means they must be possible to replace with fakes. Additionally, the test suite