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.
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.
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.
Display comments as Linear | Threaded