HTML and CSS Reference
In-Depth Information
we expected it to receive. To test this, we used a stub, as seen in Listing 16.3. Rather
than inspecting some object's state to verify its results, this test stubs the model's
publish method and then proceeds by asserting that it was called.
Listing 16.3 Inspecting a function's behavior to verify test
"test should publish message": function () {
var controller = Object.create(messageController);
var model = { notify: stubFn() };
assertEquals("message", model.notify.args[0]);
This test contrasts with the previous one that used state verification. It does
not check whether the message was stored somewhere, instead it uses behavior
verification ; it verifies that the model's publish method was called with the correct
arguments. Having already tested the Comet client to be used in production, we
know that the message will be handled correctly if publish is called this way.
16.2.3 Implications of Verification Strategy
The chosen verification strategy directly influences how a test reads, which is obvious
from looking at the two tests above. Less clear is the fact that the verification strategy
also influences production code, as well as its relationship to the tests.
Behavior verification taps into the system's implementation by expecting certain
function calls to take place. On the other hand, state verification is a mere obser-
vation on the (direct or indirect) input/output relationship. This means that using
behavior verification extensively couples the test code tighter to the system, which
in turn limits our ability to change its implementation, e.g., through refactoring,
without also having to change the tests.
16.3 Stubs
Stubs are test doubles with pre-programmed behavior. They may return a specific
value, regardless of received arguments, or throw an exception. Because stubs are
used in place of real objects and functions, they are also used as a measure to avoid
bumping into inconvenient interfaces.
Search WWH ::

Custom Search