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

this.client.connect();
assertFalse(ajax.poll.called);
}
Another less obvious source of re-testing the same behavior is covering browser
inconsistencies in the wrong places. If you find yourself testing for DOM-related
quirks inside a method whose purpose is not to cover the specific quirk, you need
to move the offending code into a dedicated function. This way you can verify that
performBuggyDOMRoutine handles all the DOM quirkiness properly across
browsers, and simply verify that depending interfaces use this method.
17.2.3 Isolate Behavior in Tests
When we test a single behavior at a time, pinpointing the source of error when tests
fail is easy. However, discrepancies in indirect inputs may distort the results, causing
tests to fail not because the targeted logic is faulty, but because it's dependencies are
behaving in unexpected ways. Back in Part I, Test-Driven Development, we referred
to these kinds of tests as “accidental integration tests.” That sure sounds bad, but
as we are about to discover, it does not need to be.
17.2.3.1 Isolation by Mocking and Stubbing
One way to completely isolate a unit is to stub or mock all of its dependencies.
Some people will tell you this is in fact the only way to properly isolate behavior.
Throughout Part III, Real-World Test-Driven Development in JavaScript, there are
lots of examples of tests that stub generously to isolate behavior. Listing 17.11,
originally from Chapter 15, TDD and DOM Manipulation: The Chat Client, shows
a test for the chat client message form controller that stubs all the objects that
handleSubmit interacts with in order to verify that the message is published
through the model object.
Listing 17.11 Stubbing all dependencies
TestCase("FormControllerHandleSubmitTest", {
"test should publish message": function () {
var controller = Object.create(messageController);
var model = { notify: stubFn() };
controller.setModel(model);
controller.handleSubmit();