HTML and CSS Reference
In-Depth Information
TestCase("ReadyStateHandlerTest", {
setUp: setUp,
tearDown: tearDown,
/* ... */
});
TestCase("RequestTest", {
setUp: setUp,
tearDown: tearDown,
"test should use specified request method": function () {
ajax.request("/uri", { method: "POST" });
assertEquals("POST", this.xhr.open.args[0]);
}
});
We add a new test case for the
ajax.request
method. This makes three test
cases using the same setup and teardown methods, so we extract them as functions
inside the anonymous closure to share them across test cases.
The test asserts that the request method uses POST as the request method
when specified to do so. The choice of method is not coincidental. When TDD-
ing, we should always add tests that we expect to fail somehow, tests that signify
progress. Using POST also forces us to produce a real solution, as hard-coding
POST would make one of the other tests fail. This is another quality mark of a unit
test suite; breaking fundamental behavior in production code only results in one (or
a few) breaking tests. This indicates tests are distinct and don't retest already tested
behavior.
Onwards to a solution. Listing 12.53 shows how
ajax.request
could make
the request method a configuration option.
Listing 12.53
Making the method configurable
function request(url, options) {
/* ... */
transport.open(options.method
||
"GET", url, true);
/* ... */
}
That's really all there is to it. Tests are passing.
