HTML and CSS Reference
In-Depth Information
client.dispatch({ someEvent: [{ id: 1234 }] });
var args = client.observers.notify.args;
assertEquals("someEvent", args[0]);
assertEquals({ id: 1234 }, args[1]);
Testing only a single behavior in any given test means that when it fails, the
source of failure will be obvious. This is a huge benefit because following this
guideline will completely eradicate the need of a debugger to test the innards of a
method. This single behavior focus also helps make the tests easier to understand.
17.2.2 Test Each Behavior Only Once
Re-testing behaviors already covered in existing tests adds no value to the spec-
ification of the system, neither does it help find bugs. It does, however, add to
the maintenance burden. Testing the same behavior in more than one test means
more tests to update whenever we want to change the behavior, and it means more
tests will fail for the exact same reason, reducing the test case's ability to pinpoint
erroneous behavior.
The most common source of duplicated verification comes from negligence;
while testing each aspect of a method in dedicated tests, it is easy to inadvertently
introduce an overlap between tests if we don't pay close attention. Another possible
reason for re-testing verified behavior is lack of trust. If we trust our tests, there is
no reason to question a previous test's validity by repeating an assertion.
Listing 17.10 shows a test from Chapter 13, Streaming Data with Ajax and
Comet, in which we expect the cometClient not to start polling a second time
if connect has already been called once. Notice how the test simply assumes that
the first call works as expected. The behavior of the first call is covered by other
tests, and there is no need to assert that ajax.poll was called the first time.
Listing 17.10 Assuming connect works the first time
"test should not connect if connected": function () {
this.client.url = "/my/url";
ajax.poll = stubFn({});
ajax.poll = stubFn({});
Search WWH ::

Custom Search