HTML and CSS Reference
In-Depth Information
Running the tests again confirms that the existence test passes, but the original
test expecting an exception now fails. This is all good and leads us to the next step,
seen in Listing 13.8; throwing an exception for the missing URL.
Listing 13.8 Throwing an exception for missing URL
function start() {
if (!this.url) {
throw new TypeError("Must specify URL to poll");
Running the tests over confirms that they are successful. Deciding the Stubbing Strategy
Once a URL is set, the start method should make its first request. At this point
we have a choice to make. We still don't want to make actual requests to the server
in the tests, so we will continue stubbing like we did in the previous chapter. How-
ever, at this point we have a choice of where to stub. We could keep stubbing
ajax.create and have it return a fake request object, or we could hook in higher
up, stubbing the ajax.request method. Both approaches have their pros and
Some developers will always prefer stubbing and mocking as many of an inter-
face's dependencies as possible (you might even see the term mockists used about
these developers). This approach is common in behavior-driven development. Fol-
lowing the mockist way means stubbing (or mocking, but we'll deal with that in
Chapter 16, Mocking and Stubbing ) ajax.request and possibly other non-trivial
dependencies. The advantage of the mockist approach is that it allows us to freely
decide development strategy. For instance, by stubbing all of the poller's dependen-
cies, we could easily have built this object first and then used the stubbed calls as
starting points for tests for the request interface when we were done. This strategy
is known as top-down—in contrast to the current bottom-up strategy—and it even
allows a team to work in parallel on dependent interfaces.
The opposite approach is to stub and mock as little as possible; only fake those
dependencies that are truly inconvenient, slow, or complicated to setup and/or run
through in tests. In a dynamically typed language such as JavaScript, stubs and mocks
come with a price; because the interface of a test double cannot be enforced (e.g., by
an “implements” keyword or similar) in a practical way, there is a real possibility of
using fakes in tests that are incompatible with their production counterparts. Making
tests succeed with such fakes will guarantee the resulting code will break when faced
with the real implementation in an integration test, or worse, in production.
Search WWH ::

Custom Search