HTML and CSS Reference
In-Depth Information
2.2.3 Step 3: Make the Test Pass
Once we have confirmed that the test fails, and that it fails in the expected way,
we have work to do. At this point test-driven development instructs us to provide
the simplest solution that could possibly work
. In other words, our only goal is to
make the tests green, by any means necessary, occasionally even by hard-coding. No
matter how messy a solution we provide in this step, refactoring and subsequent
steps will help us sort it out eventually. Don't fear hard-coding. There is a certain
rhythm to the test-driven development process, and the power of getting through
an iteration even though the provided solution is not perfect
at the moment
should
not be underestimated. Usually we make a quick judgement call: is there an obvious
implementation? If there is, go with it; if there isn't, fake it, and further steps
will gradually make the implementation obvious. Deferring the real solution may
also provide enough insight to help solve the problem in a better way at a later
point.
If there is an obvious solution to a test, we can go ahead and implement it. But
we must remember to only add enough code to make the test pass, even when we
feel that the greater picture is just as obvious. These are the “insights” I was talking
about in Section 2.2,
The Process,
and we should make a note of it and add it in
another iteration. Adding more code means adding behavior, and added behavior
should be represented by added requirements. If a piece of code cannot be backed
up by a clear requirement, it's nothing more than bloat, bloat that will cost us by
making code harder to read, harder to maintain, and harder to keep stable.
2.2.3.1 You Ain't Gonna Need It
In extreme programming, the software development methodology from which test-
driven development stems, “you ain't gonna need it,” or YAGNI for short, is the
principle that we should not add functionality until it is necessary [4]. Adding code
under the assumption that it will do us good some day is adding bloat to the code base
without a clear use case demonstrating the need for it. In a dynamic language such
as JavaScript, it is especially tempting to violate this principle in the face of added
flexibility. One example of a YAGNI violation I personally have committed more
than once is to be overly flexible on method arguments. Just because a JavaScript
function can accept a variable amount of arguments of any type does not mean every
function should cater for any combination of arguments possible. Until there is a
test that demonstrates a reasonable use for the added code, don't add it. At best,
we can write down such ideas on the to do list, and prioritize it before launching a
new iteration.
