We are trying to implement QUnit JavaScript tests for a JS-heavy web app. We are struggling to find a way to successfully test methods that involve jQuery AJAX requests. For example, we have the following constructor function (obviously this is a very simplistic example):
var X = function() {
this.fire = function() {
$.ajax("someURL.php", {
data: {
userId: "james"
},
dataType: "json",
success: function(data) {
//Do stuff
}
});
};
};
var myX = new X();
myX.fire();
We are trying to find a way to test the fire
method, preferably with a stubbed URL instead of the real someURL.php
.
The only obvious solution to me at the moment is add the URL, and the success
callback, as arguments to the constructor function. That way, in the test, we can create a new instance of X
and pass in the stub URL, and a callback to run when the stub returns a response. For example:
test("Test AJAX function", function() {
stop();
var myX = new X();
//Call the AJAX function, passing in the stub URL and success callback
myX.fire("stub.php", function(data) {
console.log(data);
start();
});
});
However, this doesn't seem like a very nice solution. Is there a better way?
With jQuery, you can use the xhr object that
.ajax()
returns as a promise, so you can add more handlers (see below) than just the singlesuccess
,complete
anderror
ones you define in the options. So if your async function can return the xhr object, you can add test-specific handlers.As for the URL, that's a little trickier. I've sometimes set up a very simple Node server on localhost, which just serves canned responses that were copied from the real server. If you run your test suite off that same server, your URLs just need to be absolute paths to hit the test server instead of the production server. And you also get a record of the requests themselves, as a server sees them. Or you can have the test server send back errors or bad responses on purpose, if you want to see how the code handles it.
But that's of course a pretty complex solution. The easier one would be to define your URLs in a place where you can redefine them from the test suite. For instance:
Also, QUnit has an
asyncTest
function, which callsstop()
for you. Add a tiny helper to keep track of when to start again, and you've got a pretty good solution.Here's what I've done before
Basically
countDown
is a function that counts down to zero from whatever you specify, and then callsstart()
. In this case, there's 1 async call, socountDown
will count down from that. And it'll do so when the ajax call finishes, regardless of how it went, since it's set up as analways
callback.And because the
asyncTest
is told to expect 2 assertions, it'll report an error if the.done()
callback is never called, since no assertions will be run. So if the call completely fails, you'll know that too. If you want to log something on error, you can add a.fail()
callback to the promise chain.Try using
jQuery spy
. I have created an easier way to use jQuery familiar syntax for testing ajax.Check this link
If it's a unit test that can (and should) be run in isolation from the server side, you can simply "replace"
$.ajax
to simulate whatever behavior. One easy example:Obviously you can also perform a real ajax call with stubbed url/data:
If you haven't a complex response, I prefer the first approach, because it is faster and easy to comprehend.
However, you can also take another way and put the Ajax logic in it's own method, so you can easily stub it during tests.