Writing Good Unit Tests - Test-Driven JavaScript Development - page 465

Physically separating setup, exercise, and verification makes it dead simple to see
what setup is required and how to exercise the given behavior, as well as identifying
the success criteria.
17.1.3 Use Higher-Level Abstractions to Keep Tests Simple
Unit tests should always target a single behavior, nothing more. Usually this corre-
lates with a single assertion per test, but some behaviors are more complex to verify,
thus requiring more assertions. Whenever we find ourselves repeating the same set
of two or three assertions, we should consider introducing higher-level abstractions
to keep tests short and clear.
17.1.3.1 Custom Assertions: Behavior Verification
Custom assertions are one way to abstract away compound verification. The most
glaring example of this from Part III, Real-World Test-Driven Development in
JavaScript, is the behavior verification of the stubs. Listing 17.4 shows a slightly
modified test for the Comet client that expects the client's observers to be notified
when the dispatch method is called.
Listing 17.4 Expecting observers to be notified
"test dispatch should notify observers": function () {
var client = Object.create(ajax.cometClient);
client.observers = { notify: stubFn() };
client.dispatch({ someEvent: [{ id: 1234 }] });
var args = client.observers.notify.args;
assert(client.observers.notify.called);
assertEquals("someEvent", args[0]);
assertEquals({ id: 1234 }, args[1]);
}
Using the Sinon stubbing library introduced in Chapter 16, Mocking and
Stubbing, we can verify the test using Sinon's higher-level assertCalledWith
method instead, which makes the test more clearly state its intent, as seen in Listing
17.5.