JavaScript testing – Requests | Rohde's geeky corner

JavaScript testing – Requests

Posted by Rohde Fischer on Monday, January 14. 2013

Dog is testing the the crackers for poison.

When testing JavaScript you might have run into the problem of testing requests, such as XmlHttpRequests (XHR). You might also have run into an awesome way of testing it such as the one provided by Buster.js (which in turn uses Sinon.js). These tools are really powerful and awesome, if you haven’t tried them yet go do it.

One problem though. A unit test is supposed to be as implementation independent as possible, and testing XHR is rather tightly bound to the implementation. If I suddenly start requesting resources by adding script tags to the dom my tests will fail even though the solution is solid. We don’t want that.

To solve the challenge I’ve considered multiple strategies, on of them ended up with me writing a small addition to the Buster.js testing framework. An assert.urlRequested(server, url[, message]) that basically takes an fakeServer and an URL to test if a request have been made to a certain URL. The additions is called RfBusterAssertions and can be found on my GitHub.

buster.testCase("Test assertions", { setUp: function() { this.server = this.useFakeServer(); }, "An simple XHR test": function() { var request = new XMLHttpRequest(); request.open('GET', "foo.js", false); request.send(); assert.urlRequest(this.server, "foo.js"); expect(this.server).toHaveRequestedUrl("foo.js"); }, "An simple script test": function() { var script = document.createElement('script'); script.type = "text/javascript"; script.src = "foo.js"; document.head.appendChild(script) assert.urlRequest(this.server, "foo.js"); expect(this.server).toHaveRequestedUrl("foo.js"); } });

What is basically does is to run through all script-tags on the page and check the src-argument for the specified URL and to run through all the registered requests on the server and check for their URLs. This covers the normal ways to load resources. Unfortunately this still won’t handle things like loading through Flash, Java Applets and different other resources, if you do that you’ll probably have to write the test yourself.

Another strategy I’ve considered (and have used) is by having a URL property on the object I’m testing and then setting it to a local JavaScript file that launches a predefined callback. This have the advantage of both testing the configuration option and being completely independent. The disadvantages is that, if I don’t use XHR I have no way to test the get parameters, also this add details that can cause the test to fail.

/ The contents of js-file should be: window.testCb(); / buster.testCase("Callback", { setUp: function() { // Note when having a fake server you have to manipulate the // result to contain the script in the comment above. this.server = this.useFakeServer(); }, "An simple callback test": function(done) { window.testCb = function() { // There's probably a better, way this is just // to ensure an assertion that will be true no matter what assert.equals(true, true); done() } var script = document.createElement("script"); script.type = "text/javascript"; script.src = "callback.js"; document.head.appendChild(script); } });

The last way of testing that I have considered but completely discarded is good on the technical part, but will most likely end up too impractical. I would be possible to write a server component that answers to an callback, but adds all the meta data as a param to the callback. Thus it would be possible to test things in the callback such as get parameters. This I deemed too impractical due to the amount of setup needed and honestly I think it’s better to have a decent test that’s used rather than a really good test that ain’t.

Special thanks to Christian Johansen for all his help on these tests.

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as Linear | Threaded

No comments

Add Comment

Name*

Homepage

Comment*

In reply to

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.

Standard emoticons like :-) and ;-) are converted to images.

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Enter the string from the spam-prevention image above:

Form options

Remember Information?

Subscribe to this entry