HTML and CSS Reference
In-Depth Information
function arguments and return value, and indirect inputs and outputs, i.e., any
object not passed as arguments or modifications to outside objects.
2.2.2 Step 2: Watch the Test Fail
As soon as the test is ready, we run it. Knowing it's going to fail may make this
step feel redundant. After all, we wrote it specifically to fail, didn't we? There are
a number of reasons to run the test before writing the passing code. The most
important reason is that it allows us to confirm our theories about the current state
of our code. While writing the test, there should be a clear expectation on
how
the
test is going to fail. Unit tests are code too, and just like other code it may contain
bugs. However, because unit tests should never contain branching logic, and rarely
contain anything other than a few lines of simple statements, bugs are less likely, but
they still occur. Running the test with an expectation on what is going to happen
greatly increases the chance of catching bugs in the tests themselves.
Ideally, running the tests should be fast enough to allow us to run
all
the tests
each time we add a new one. Doing this makes it easier to catch interfering tests,
i.e., where one test depends on the presence of another test, or fails in the presence
of another test.
Running the test before writing the passing code may also teach us something
new about the code we are writing. In some cases we may experience that a test
passes before we have written any code at all. Normally, this should not happen,
because TDD only instructs us to add tests we expect to fail, but nevertheless, it may
occur. A test may pass because we added a test for a requirement that is implicitly
supported by our implementation, for instance, due to type coercion. When this
happens we can remove the test, or keep it in as a stated requirement. It is also
possible that a test will pass because the current environment already supports
whatever it is we are trying to add. Had we run the
String.prototype.trim
method test in Firefox, we would discover that Firefox (as well as other browsers)
already support this method, prompting us to implement the method in a way that
preserves the native implementation when it exists.
1
Such a discovery is a good to
do list candidate. Right now we are in the process of adding the
trim
method.
We will make a note that a new requirement is to preserve native implementations
where they exist.
1. In fact, ECMAScript 5, the latest edition of the specification behind JavaScript, codifies String.
prototype.trim, so we can expect it to be available in all browsers in the not-so-distant future.
