HTML and CSS Reference
In-Depth Information
12.6.1.3 Updating
ajax.get
Now to the actual refactoring.
ajax.request
now does the same job as
ajax.get
, only slightly more flexible. This means that all
ajax.get
really needs
to do is to make sure the method used is GET and let
ajax.request
do all the
work. Listing 12.54 shows the spiffy new
ajax.get
.
Listing 12.54
Cropping
ajax.get
's body
function get(url, options) {
options = tddjs.extend({}, options);
options.method = "GET";
ajax.request(url, options);
}
As we are now overriding the
method
option, we use the
tddjs.extend
method from Chapter 7,
Objects and Prototypal Inheritance,
to make a copy of the
options
object before making changes to it. Running the tests confirms that this
works as expected, and voila, we have a foundation for the post method.
Now that the interface changed, our tests are in need of some maintenance. Most
tests now target
ajax.get
while actually testing the internals of
ajax.request
.
As we discussed as early as in Chapter 1,
Automated Testing,
voila, this kind of
indirection in tests is generally not appreciated. Unit tests need maintenance as
much as production code, and the key to avoiding that becoming a problem is
dealing with these cases as they arise. In other words, we should update our test
cases immediately.
Fortunately, housekeeping is simple at this point. All the tests except “should
define get method” can be moved from GetRequestTest to RequestTest. The only
modification we need to make is to change all calls to
get
to
request
directly.
The tests for the ready state change handler already have their own test case, Ready-
StateHandlerTest. In this case we only need to update the method calls from
get
to
request
. This includes the call inside the
forceStatusAndReadyState
helper.
Moving tests, changing method calls, and re-running the tests takes about half
a minute, no big deal. In more complex situations, such changes may be more
involved, and in those cases some folks feel it's a good idea to employ more test
helpers to avoid coupling the tests too tightly to the interface being tested. I think
this practice takes away some of the value of tests as documentation, and I use it
sparingly.
