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

case of the misspelled method name, you probably would notice the mistake either
while initially writing it, during the initial run or, while writing it again in production
code. If the mismatch between the test double and the real object was the wrong
order or number of arguments passed to a method, it would not have been as
obvious.
While writing the code for the chat server originally covered in Chapter 14,
Server-Side JavaScript with Node.js, I did in fact make such a mistake. In my ini-
tial attempt at the controller's get method, I made a mistake while constructing
the expected output. As you might remember, the server was supposed to emit
JSON responses that would work with the cometClient . Because my initial
expectations deviated from the actual format used by the client object, the chat
server did not work as expected upon finishing it, even though all the tests passed.
The change to make it work was a simple one, but ideally we should avoid such
mistakes.
This is not to say you shouldn't use stubs and mocks in your tests. They are
effective tools, but need to be used with some care and attention. Always make
sure to double check that your test doubles properly mirror the real deal. One way
to achieve this is to use a real object as a starting point for the stub or mock. For
instance, imagine a method like sinon.stubEverything(target) , which
could be used to create a stub object with stub function properties corresponding
to all the methods of the target object. This way you take away the chance of
using a fake method that doesn't exist in production code.
17.2.3.3 Isolation by Trust
Another way to isolate units is to make sure that any object the unit interacts with
can somehow be trusted. Obviously, mocks and stubs can generally be trusted so
long as they properly mirror the objects they mimic.
Objects that are already tested can also be trusted. The same should be true
for any third party library code in use. When dependencies are previously tested
and known to work as expected, the chance of failing a test due to uncooperative
dependencies is small enough to provide acceptable isolation.
Although such tests can be considered “accidental integration tests,” they usu-
ally integrate only a small group of objects, and do so in a controlled manner. The
up side to using real objects is that we can use state verification, thus loosening
the coupling between test code and production code. This gives us more room to
refactor the implementation without having to change the tests, thus reducing the
maintenance burden of the application as a whole.