Test Driven JavaScript Development- P15 docx

ptg 12.5 Using the Ajax API 273 requestComplete(transport, options); transport.onreadystatechange = tddjs.noop; } }; transport.send(null); }; /* */ }()); Adding these two lines makes the tests pass again. Re-running the massive re- quest integration test in Internet Explorer confirms that the memory leak is now gone. 12.5.4 Local Requests The last issue with the current implementation is that it is unable to make local requests. Doing so results in no errors, yet “nothing happens.” The reason for this is that the local file system has no concept of HTTP status codes, so the status code is 0 when readyState is 4. Currently our implementation only accepts status code 200, which is insufficient in any case. We will add support for local requests by checking if the script is running locally and that the status code is not set, as the test in Listing 12.44 shows. Listing 12.44 Making sure the success handler is called for local requests "test should call success handler for local requests": function () { this.xhr.readyState = 4; this.xhr.status = 0; var success = stubFn(); tddjs.isLocal = stubFn(true); ajax.get("file.html", { success: success }); this.xhr.onreadystatechange(); assert(success.called); } The test assumes a helper method tddjs.isLocal to check if the script is running locally. Because we are stubbing it, a reference to it is saved in the setUp, allowing it to be restored in tearDown as we did before. From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 274 Abstracting Browser Differences: Ajax To pass the test, we will call the success callback whenever the request is for a local file and the status code is not set. Listing 12.45 shows the updated ready state change handler. Listing 12.45 Allow local requests to succeed function requestComplete(transport, options) { var status = transport.status; if (status == 200 || (tddjs.isLocal() && !status)) { if (typeof options.success == "function") { options.success(transport); } } } The implementation passes the test. In order to have this working in a browser as well, we need to implement the helper that determines if the script is running locally, as seen in Listing 12.46. Add it to the lib/tdd.js file. Listing 12.46 Checking current URL to decide if request is local tddjs.isLocal = (function () { function isLocal() { return !!(window.location && window.location.protocol.indexOf("file:") === 0); } return isLocal; }()); With this helper in place we can re-run the integration test locally, and observe that it now loads the HTML fragment. 12.5.5 Testing Statuses We finished another step—a test and a few lines of production code—it’s time to review and look for duplication. Even with the stub helpers we added previously, the tests that verify behavior for different sets of readyState and status codes look awfully similar. And still we haven’t tested for other 2xx status codes, or any error codes at all. To reduce the duplication, we will add a method to the fakeXMLHttp- Request object that allows us to fake its ready state changing. Listing 12.47 adds a method that changes the readystate and calls the onreadystatechange handler. From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 12.5 Using the Ajax API 275 Listing 12.47 Completing the fake request var fakeXMLHttpRequest = { open: stubFn(), send: stubFn(), readyStateChange: function (readyState) { this.readyState = readyState; this.onreadystatechange(); } }; Using this method, we can extract a helper method that accepts as arguments a status code and a ready state, and returns an object with properties success and failure, both indicating if the corresponding callback was called. This is a bit of a leap because we haven’t yet written any tests for the failure callback, but in order to move along we will make a run for it. Listing 12.48 shows the new helper function. Listing 12.48 Request helper for tests function forceStatusAndReadyState(xhr, status, rs) { var success = stubFn(); var failure = stubFn(); ajax.get("/url", { success: success, failure: failure }); xhr.status = status; xhr.readyStateChange(rs); return { success: success.called, failure: failure.called }; } Because this abstracts the whole body of a few tests, it was given a fairly verbose name so as to not take away from the clarity of the tests. You’ll be the judge of whether the tests are now too abstract or still clear. Listing 12.49 shows the helper in use. From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 276 Abstracting Browser Differences: Ajax Listing 12.49 Using the request helper in tests "test should call success handler for status 200": function () { var request = forceStatusAndReadyState(this.xhr, 200, 4); assert(request.success); }, /* */ "test should call success handler for local requests": function () { tddjs.isLocal = stubFn(true); var request = forceStatusAndReadyState(this.xhr, 0, 4); assert(request.success); } When making big changes like this I like to introduce a few intentional bugs in the helper to make sure it’s working as I expect. For instance, we could com- ment out the line that sets the success handler in the helper to verify that the test then fails. Also, the second test should fail if we comment out the line that stubs tddjs.isLocal to return true, which it does. Manipulating the ready state and status code is also a good way to ensure tests still behave as expected. 12.5.5.1 Further Status Code Tests Using the new helper makes testing for new status codes a trivial task, so I will leave it as an exercise. Although testing for more status codes and making sure the failure callback is fired for status codes outside the 200 range (with the exception of 0 for local files and 304 “Not Modified”) is a good exercise in test-driven development, doing so will add little new to our discussion. I urge you to run through the steps as an exercise, and when you are done you could always compare your quest to mine by downloading the sample code off the book’s website 2 . 2. http://tddjs.com From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 12.6 Making POST Requests 277 Listing 12.50 shows the resulting handler. Listing 12.50 Dispatching success and failure callbacks function isSuccess(transport) { var status = transport.status; return (status >= 200 && status < 300) || status == 304 || (tddjs.isLocal() && !status); } function requestComplete(transport, options) { if (isSuccess(transport)) { if (typeof options.success == "function") { options.success(transport); } } else { if (typeof options.failure == "function") { options.failure(transport); } } } 12.6 Making POST Requests With the GET requests in a fairly usable state we will move on to the subject of POST requests. Note that there is still a lot missing from the GET implementation, such as setting request headers and exposing the transport’s abort method. Don’t worry, test-driven development is all about incrementally building an API, and given a list of requirements to meet we can choose freely which ones makes sense to work on at any given time. Implementing POST requests will bring about an interesting refactoring, which is the motivation for doing this now. 12.6.1 Making Room for Posts The current implementation does not lend itself easily to support new HTTP verbs. We could pass the method as an option, but where? To the ajax.get method? That wouldn’t make much sense. We need to refactor the existing implementation in three ways: First we need to extract a generic ajax.request method; then we need to make the HTTP verb configurable. Last, to remove duplication we will From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 278 Abstracting Browser Differences: Ajax “nuke” the body of the ajax.get method, leaving it to delegate its work to ajax.request, forcing a GET request. 12.6.1.1 Extracting ajax.request Extracting the new method isn’t magic; simply copy-paste ajax.get and rename it, as seen in Listing 12.51. Listing 12.51 Copy-pasting ajax.get to ajax.request function request(url, options) { // Copy of original ajax.get function body } ajax.request = request; Remember to run the tests after each step while refactoring. In this case, only a copy-paste mistake resulting in a syntax error could possibly break the code because the new method isn’t being called yet. 12.6.1.2 Making the Method Configurable Next up is to make the request method a configurable option on the ajax. request method. This is new functionality and so requires a test, as seen in Listing 12.52. Listing 12.52 Request method should be configurable function setUp() { this.tddjsIsLocal = tddjs.isLocal; this.ajaxCreate = ajax.create; this.xhr = Object.create(fakeXMLHttpRequest); ajax.create = stubFn(this.xhr); } function tearDown() { tddjs.isLocal = this.tddjsIsLocal; ajax.create = this.ajaxCreate; } TestCase("GetRequestTest", { setUp: setUp, tearDown: tearDown, /* */ }); From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 12.6 Making POST Requests 279 TestCase("ReadyStateHandlerTest", { setUp: setUp, tearDown: tearDown, /* */ }); TestCase("RequestTest", { setUp: setUp, tearDown: tearDown, "test should use specified request method": function () { ajax.request("/uri", { method: "POST" }); assertEquals("POST", this.xhr.open.args[0]); } }); We add a new test case for the ajax.request method. This makes three test cases using the same setup and teardown methods, so we extract them as functions inside the anonymous closure to share them across test cases. The test asserts that the request method uses POST as the request method when specified to do so. The choice of method is not coincidental. When TDD- ing, we should always add tests that we expect to fail somehow, tests that signify progress. Using POST also forces us to produce a real solution, as hard-coding POST would make one of the other tests fail. This is another quality mark of a unit test suite; breaking fundamental behavior in production code only results in one (or a few) breaking tests. This indicates tests are distinct and don’t retest already tested behavior. Onwards to a solution. Listing 12.53 shows how ajax.request could make the request method a configuration option. Listing 12.53 Making the method configurable function request(url, options) { /* */ transport.open(options.method || "GET", url, true); /* */ } That’s really all there is to it. Tests are passing. From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 280 Abstracting Browser Differences: Ajax 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 inneed of somemaintenance. 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. From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 12.6 Making POST Requests 281 12.6.1.4 Introducing ajax.post With ajax.request in place, implementing POST requests should be a breeze. Feeling brave, we skip the simple test to prove the method’s existence this time around. Instead, the test in Listing 12.55 shows how we expect the method to behave. Listing 12.55 Expecting ajax.post to delegate to ajax.request TestCase("PostRequestTest", { setUp: function () { this.ajaxRequest = ajax.request; }, tearDown: function () { ajax.request = this.ajaxRequest; }, "test should call request with POST method": function () { ajax.request = stubFn(); ajax.post("/url"); assertEquals("POST", ajax.request.args[1].method); } }); Implementation is trivial, as seen in Listing 12.56. Listing 12.56 Delegating ajax.post to ajax.request with POST as method function post(url, options) { options = tddjs.extend({}, options); options.method = "POST"; ajax.request(url, options); } ajax.post = post; Running the tests confirms that this implementation solves the newly added requirement. As always, we look for duplication before moving on. Obviously, the get and post methods are very similar. We could extract a helper method, but saving only two lines in two methods at the expense of another function call and another level of indirection doesn’t seem worthwhile at this point. You may feel differently. From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 282 Abstracting Browser Differences: Ajax 12.6.2 Sending Data In order for the POST request to make any sense, we need to send data with it. To send data to the server the same way a browser posts a form we need to do two things: encode the data using either encodeURI or encodeURIComponent (depending on how we receive the data) and set the Content-Type header. We will start with the data. Before we head into the request test case to formulate atest that expectsencoded data, let’s take a step back and consider what we are doing. Encoding strings isn’t a task unique to server requests; it could be useful in other cases as well. This insight points in the direction of separating string encoding into its own interface. I won’t go through the steps required to build such an interface here; instead Listing 12.57 shows a very simple implementation. Listing 12.57 Simplified url parameter encoder (function () { if (typeof encodeURIComponent == "undefined") { return; } function urlParams(object) { if (!object) { return ""; } if (typeof object == "string") { return encodeURI(object); } var pieces = []; tddjs.each(object, function (prop, val) { pieces.push(encodeURIComponent(prop) + "=" + encodeURIComponent(val)); }); return pieces.join("&"); } tddjs.namespace("util").urlParams = urlParams; }()); From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... Differences: Ajax The test cases (or test suite if you will) built in this chapter provide some insight into the kind of tests TDD leaves you with Even with close to 100% code coverage (every line of code is executed by the tests), we have several holes in tests; more tests for cases when things go wrong—methods receive the wrong kind of arguments, and other edge cases are needed Even so, the tests document... missing argument Note that because the encoding interface was separated from the ajax interface, it would probably be a good idea to add a feature test for it We could force such a feature test by writing a test that removed the method locally for the duration of the test and assert that the method did not throw an exception I’ll leave that as an exercise 12.6.2.2 Sending Encoded Data Next up is sending the... to provide the expected value It should have its own set of tests, which should guarantee as much If we are reluctant to trust it, we could stub it out to avoid it cluttering up the test Some developers always stub or mock out dependencies such as this, and theoretically, not doing so makes the unit test slightly bend toward an integration test We will discuss pros and cons of different levels of stubbing... passed as an argument to the send method Let’s start by writing a test that ensures data is encoded, as in Listing 12.58 Listing 12.58 Asserting data sent to post function setUp() { this.tddjsUrlParams = tddjs.util.urlParams; /* */ } function tearDown() { tddjs.util.urlParams = this.tddjsUrlParams; /* */ } TestCase("RequestTest", { /* */ "test should encode data": function () { tddjs.util.urlParams =... not passed to the send method, but rather encoded on the URL Listing 12.63 shows a test specifying the behavior Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark From the Library of WoweBook.Com 286 Abstracting Browser Differences: Ajax Listing 12.63 Testing that GET requests can send data "test var var var should send data on URL for GET": function () { url = "/url"; object... and makes for an excellent start in regards to a more solid test suite 12.8 Summary In this chapter we have used tests as our driver in developing a higher level API for the XMLHttpRequest object The API deals with certain cross-browser issues, such as differing object creation, memory leaks, and buggy send methods Whenever a bug was uncovered, tests were written to ensure that the API deals with the... assertEquals(expected, this.xhr.open.args[1]); } With this test in place we need to modify the data processing For both GET and POST requests we need to encode data, but for GET requests the data goes on the URL, and we must remember to still pass null to the send method At this point we have enough requirements to make keeping them all in our heads a confusing affair Tests are slowly becoming a fantastic asset;... it As an exercise, I urge you to test for such a URL and update setData as necessary 12.6.3 Setting Request Headers The last thing we need to do in order to pass data is setting request headers Headers can be set using the setRequestHeader(name, value) method At this point adding in header handling is pretty straightforward, so I will leave doing that as an exercise To test this you will need to augment... integration test We will discuss pros and cons of different levels of stubbing and mocking more extensively in Chapter 16, Mocking and Stubbing For now, we will leave tddjs.util.urlParams live in our tests To make the test pass we need to add data handling to ajax.request, as Listing 12.61 does Listing 12.61 Initial attempt at handling data function request(url, options) { /* */ options = tddjs.extend({},... specifies Listing 12.60 Expecting data to be sent for POST requests "test should send data with send() for POST": function () { var object = { field1: "$13", field2: "Lots of data!" }; var expected = tddjs.util.urlParams(object); ajax.request("/url", { data: object, method: "POST" }); assertEquals(expected, this.xhr.send.args[0]); } This test fails because we are force-feeding the send method null Also . Requests 279 TestCase("ReadyStateHandlerTest", { setUp: setUp, tearDown: tearDown, /* */ }); TestCase("RequestTest", { setUp: setUp, tearDown: tearDown, " ;test should use. ensure tests still behave as expected. 12.5.5.1 Further Status Code Tests Using the new helper makes testing for new status codes a trivial task, so I will leave it as an exercise. Although testing. behavior in production code only results in one (or a few) breaking tests. This indicates tests are distinct and don’t retest already tested behavior. Onwards to a solution. Listing 12.53 shows how