HTML and CSS Reference
In-Depth Information
2.2.5 Lather, Rinse, Repeat
Once refactoring is completed, and there is no more duplication to remove or
improvements to be made to design, we are done. Pick a new task off the to do list
and repeat the process. Repeat as many times as necessary. As you grow confident
in the process and the code, you may want to start taking bigger steps, but keep
in mind that you want to have short cycles in order to keep the frequent feedback.
Taking too big steps lessens the value of the process because you will hit many of the
problems we are trying to avoid, such as hard to trace bugs and manual debugging.
When you are done for the day, leave one test failing so you know where to pick up
the next day.
When there are no more tests to write, the implementation is done—it fulfills
all its requirements. At this point we might want to write some more tests, this time
focusing on improving test coverage. Test-driven development by nature will ensure
that every line of code is tested, but it does not necessarily yield a sufficiently strong
test suite. When all requirements are met, we can typically work on tests that further
tests edge cases, more types of input, and most importantly, we can write integration
tests between the newly written component and any dependencies that have been
faked during development.
The string trim method has so far only been proven to remove leading white
space. The next step in the test-driven development process for this method would
be to test that trailing white space is being trimmed, as shown in Listing 2.3.
Listing 2.3 Second test for String.prototype.trim
"test trim should remove trailing white-space":
function () {
assert("should remove trailing white-space",
"a string" === "a string
".trim());
}
Now it's your turn; go ahead and complete this step by running the test, making
necessary changes to the code and finally looking for refactoring possibilities in
either the code or the test.
2.3 Facilitating Test-Driven Development
The most crucial aspect of test-driven development is running tests. The tests need
to run fast, and they need to be easy to run. If this is not the case, developers start to
skip running tests every now and then, quickly adding some features not tested for,
 
 
Search WWH ::




Custom Search