HTML and CSS Reference
In-Depth Information
2.1.1 Turning Development Upside-Down
In traditional programming problems are solved by programming until a concept is
fully represented in code. Ideally, the code follows some overall architectural design
considerations, although in many cases, perhaps especially in the world of JavaScript,
this is not the case. This style of programming solves problems by guessing at what
code is required to solve them, a strategy that can easily lead to bloated and tightly
coupled solutions. If there are no unit tests as well, solutions produced with this
approach may even contain code that is never executed, such as error handling
logic, and edge cases may not have been thoroughly tested, if tested at all.
Test-driven development turns the development cycle upside-down. Rather than
focusing on what code is required to solve a problem, test-driven development starts
by defining the goal. Unit tests form both the specification
and
documentation for
what actions are supported and accounted for. Granted, the goal of TDD is not
testing and so there is no guarantee that it handles edge cases better. However,
because each line of code is tested by a representative piece of sample code, TDD
is likely to produce less excessive code, and the functionality that is accounted for
is likely to be more robust. Proper test-driven development ensures that a system
will never contain code that is not being executed.
2.1.2 Design in Test-Driven Development
In test-driven development there is no “Big Design Up Front,” but do not mistake
that for “no design up front.” In order to write clean code that is able to scale across
the duration of a project and its lifetime beyond, we need to have a plan. TDD
will not automatically make great designs appear out of nowhere, but it will help
evolve designs as we go. By relying on unit tests, the TDD process focuses heavily on
individual components in isolation. This focus goes a long way in helping to write
decoupled code, honor the single responsibility principle, and to avoid unnecessary
bloat. The tight control over the development process provided by TDD allows for
many design decisions to be deferred until they are actually needed. This makes it
easier to cope with changing requirements, because we rarely design features that
are not needed after all, or never needed as initially expected.
Test-driven development also forces us to deal with design. Anytime a new
feature is up for addition, we start by formulating a reasonable use case in the form
of a unit test. Writing the unit test requires a mental exercise—we must describe the
problem we are trying to solve. Only when we have done that can we actually start
coding. In other words, TDD requires us to think about the results before providing
the solution. We will investigate what kind of benefits we can reap from this process
