Jasmine has this funky methodology of not halting at a first failure within a test. This is fine in general, but it doesn't come without issues. I'm wondering what the best practice is for a scenario such as this:
it('should process async results nicely', function (done) {
this.getJSON('something', function(response) {
expect(response.status).toEqual('ok');
expect(response.data).toBeDefined();
expect(response.data.length).toEqual(5);
done();
}
}
The problem here is that this will crash the whole test suite if response.data is undefined. Then again, writing conditionals within a test case is generally frowned upon. Do I have any other choice for this scenario? Given the async nature of most of the tests, this is a very common issue.
If you adhered to OAPT (One Assertion Per Test) you would not have this problem (thought you might have others.)
var resp = null;
beforeEach(function(){
this.getJSON('something', function(response){
resp = response;
});
});
it('should have a defined response', function(){
expect(resp).toBeDefined();
});
it('should have a status of OK:', function(){
expect(resp.status).toEqual('ok');
});
it('should have data:', function(){
expect(resp.data).toBeDefined();
});
it('should have a data length of 5', function(){
expect(resp.data.length).toEqual(5);
});
This probably isn't 100% accurate on how to handle the variable, but it should give you the general idea. If the first one fails (expecting the resp variable to be defined) you know that your .getJSON function is having a problem. This should work because even though a variable is set to null it is still defined. If your function fails, it will set the variable to be undefined, and thus trip the test.
Maybe something like this could do the trick:
it("should make a real AJAX request", function () {
var callback = jasmine.createSpy();
makeAjaxCall(callback);
waitsFor(function() {
return callback.callCount > 0;
}, "The Ajax call timed out.", 5000);
runs(function() {
expect(callback).toHaveBeenCalled();
});
});
function makeAjaxCall(callback) {
$.ajax({
type: "GET",
url: "data.json",
contentType: "application/json; charset=utf-8"
dataType: "json",
success: callback
});
}
Source: http://www.htmlgoodies.com/beyond/javascript/test-asynchronous-methods-using-the-jasmine-runs-and-waitfor-methods.html#fbid=-1PVhTWm6xy
The problem was basically that the errors within an AJAX block got thrown out of the context of the it() block and thus, not being caught. The solution was to write some custom error handling within a function that does the AJAX call and have it succeed or fail with the 'done' passed to the it block.
Related
I would like to test my simple API that has /groups URL.
I want to make an API request to that URL (using Axios) before all tests begin and make the response visible to all test functions.
I am trying to make the response visible but not able to make it work. I followed a similar case with filling out the DB upfront but no luck with my case.
My simple test file below:
var expect = require('chai').expect
var axios = require('axios')
var response = {};
describe('Categories', function() {
describe('Groups', function() {
before(function() {
axios.get(config.hostname + '/groups').then(function (response) {
return response;
})
});
it('returns a not empty set of results', function(done) {
expect(response).to.have.length.greaterThan(0);
done();
})
});
});
I tried also a sligh modification of before function:
before(function(done) {
axios.get(config.hostname + '/groups')
.then(function (response) {
return response;
}).then(function() {
done();
})
});
but no luck too.
The error I am getting is simply that response isn't changing nor is visible within it. AssertionError: expected {} to have property 'length'
Summarising: How can I pass response from axios inside to in()?
Your first form is incorrect, because you're not returning the chained promise. As such, mocha has no way of knowing when your before is finished, or even that it's async at all. Your second form will solve this problem, but since axios.get already returns a promise, it's kind of a waste not to use mocha's built-in promise support.
As for making the response visible in the it, you need to assign it to a variable in a scope that will be visible within the it.
var expect = require('chai').expect
var axios = require('axios')
var response;
describe('Categories', function() {
describe('Groups', function() {
before(function() {
// Note that I'm returning the chained promise here, as discussed.
return axios.get(config.hostname + '/groups').then(function (res) {
// Here's the assignment you need.
response = res;
})
});
// This test does not need the `done` because it is not asynchronous.
// It will not run until the promise returned in `before` resolves.
it('returns a not empty set of results', function() {
expect(response).to.have.length.greaterThan(0);
})
});
});
I have some mocha tests I run with Nodejs to test a web server.
Many of the tests should cause the server to return an error, e.g. 400 Bad Request.
Currently the tests are peppered with many copies of the following code:
it('should respond with 400 (Bad Request)', function (){
expect(httpResponse.statusCode).to.equal(httpstatus.BAD_REQUEST);
});
Here's a simplified pseudocode example:
describe('When passing bad JSON data', function(){
var response
before(function(done){
callUrlToInsert(url, badJson, function(err, resp){
response = resp
done()
}
}
it('should respond with 400 (Bad Request)', function (){
expect(httpResponse.statusCode).to.equal(httpstatus.BAD_REQUEST)
})
}
This bugs me because as a programmer I avoid duplicate code wherever possible.
However, putting this into a function does not work:
function verifyItReturnedBadRequest400(httpResponse)
{
it('should respond with 400 (Bad Request)', function (){
expect(httpResponse.statusCode).to.equal(httpstatus.BAD_REQUEST);
});
}
because the call to it() doesn't test the assertion right then; my [limited] understanding is that it() adds the closure to the list of tests. So by the time that check is done, the httpResponse variable has gone out of scope. (I don't understand why that is the case, because in both cases there is a call to it(); why would it matter that in one case it's inside another level of function call? I'm probably missing something with regard to Javascript scoping.)
Is there a common way to avoid all this duplicate code? Or is everyone out there duplicating all their assertion code everywhere? This is my first foray into Mocha so I am probably missing something obvious.
Also, bonus points for explaining why doesn't the function approach work?
Thanks!
There is an article on wiki about this.
https://github.com/mochajs/mocha/wiki/Shared-Behaviours
I guess you have some bugs in your test. Placing it() into wrapper function works fine. Here's a small working demo.
'use strict';
const assert = require('assert');
const xEqualsOne = () => {
it('should be equal 1', () => {
assert.equal(this.x, 1);
});
};
describe('async number', () => {
this.x = 0;
before(done => {
this.x++
setTimeout(done, 100);
});
xEqualsOne();
});
I guess your code looks something like this:
describe('When passing bad JSON data', function(){
var response
before(function(done){
callUrlToInsert(url, badJson, function(err, resp){
response = resp
done()
}
}
verifyItReturnedBadRequest400(httpResponse)
}
Think about it like this:
it() creates a test.
All the calls to it happen before any tests are actually run (you have to create tests before you run them)
The function passed to `before' is run after the tests have been created, but before they are run.
verifyItReturnedBadRequest400 calls it, to create a test, but you're passing in httpResponse right then before any tests have run, so before hasn't run yet either.
You could continue to use that sort of pattern, but you'll need to put the httpresponse in a container so you can pass a reference to it:
describe('When passing bad JSON data', function(){
var data = {};
before(function(done){
callUrlToInsert(url, badJson, function(err, resp){
data.response = resp
done()
}
}
verifyItReturnedBadRequest400(data)
}
and then your verifyItReturnedBadRequest400 becomes:
function verifyItReturnedBadRequest400(data) {
it('should respond with 400 (Bad Request)', function (){
expect(data.response.statusCode).to.equal(httpstatus.BAD_REQUEST);
});
}
describe("Company Controller", function() {
var apiUrl;
beforeEach(function(done) {
apiUrl = "http://localhost:3001";
done();
});
it('should register a client without error and return an API key', function(done) {
request({
uri: apiUrl + '/api/v1/company',
method: 'POST',
json: true,
form: {
name: 'My Company'
}
}, function(err, res, body) {
should.not.exist(err);
res.statusCode.should.eql(200);
body.status.should.eql('ok');
should.exist(body.company.api_key);
done();
});
});
it('should generate a new API key for a company', function(done) {
// NEED THE client_id generated in the previous test
});
after(function(done) {
Company.remove().exec();
done();
});
});
How do I get the client_id in the next test?
Generally speaking, making tests with side effects is a brittle practice. Do this often enough, you'll start to encounter some very difficult-to-debug errors where your test suite fails even though every test runs in isolation, and the error messages won't be any help. Ideally every test should "leave the campground" in the same state that it found it.
If you're really insistent on doing this, you could of course set a global variable. Some other options include:
Merging the two tests. Yes, this violates a principle of Single-Assertion-Per-Test that some people hold, but I think the Avoid-Side-Effects principle trumps that one.
Put the registration in the beforeEach function. Yes, by doing this you'll be registering multiple clients per test suite run. This is still my preferred approach.
You should use a stub. For example sinonjs. This way you use a fake function to test another. You don't need to use beforeEach and afterEach if you only need to stub the function once you can define it inside the it function.
describe("Company controller", function() {
describe("dependantFunction()", function() {
var stub;
beforeEach(function() {
stub = sinon.stub(module, 'targetFunction');
stub.onCall(0).callsArgWith(1, ...some valid results...);
stub.onCall(1).callsArgWith(1, ...some expected error...);
stub.throws();
});
afterEach(function() {
stub.restore();
});
it("should do something", function() {
var result;
module.targetfunction(null, result);
dependantfunction(result);
....your tests here....
});
it("should do something else", function() {
...
});
});
});
I'm trying out the chai-http plugin for Mocha/Chai. Which wraps around Superagent. Everything seems to work well, except I'm wondering...
Shouldn't I be able to make the http call once and write separate tests for each? The tests seem to expect you to write your assertion inside the response function like so:
describe "github test", ->
it "should connect with a 200 status", ->
chai.request(githubReqObj.base)
.get(githubReqObj.url)
.req (req) ->
req.set
'Accept': 'application/vnd.github.beta+json'
return
.res (res) ->
expect(res).to.have.status 200
But I want to run several assertions, and have each of them under their own "it" block.
Is there a way to run
before ->
And then just call my assertions on the value of response?
Yep, like this:
describe("github test", function () {
var res;
before(function (done) {
chai.request(...)
.get(..)
.req(...)
.res(function (response) {
res = response; // Record the response for the tests.
done(); // Tell mocha that the ``before`` callback is done.
});
});
it("should connect with a 200 status", function () {
expect(res).to.have.status(200);
});
it("should whaterver", function () {
expect(res).whatever;
});
});
I notice you did not use the done callback in your example. It's really important to use it for asynchronous tests. In the code I show above, the before callback is asynchronous but the tests themselves are synchronous.
In my node application I'm using mocha to test my code. While calling many asynchronous functions using mocha, I'm getting timeout error (Error: timeout of 2000ms exceeded.). How can I resolve this?
var module = require('../lib/myModule');
var should = require('chai').should();
describe('Testing Module', function() {
it('Save Data', function(done) {
this.timeout(15000);
var data = {
a: 'aa',
b: 'bb'
};
module.save(data, function(err, res) {
should.not.exist(err);
done();
});
});
it('Get Data By Id', function(done) {
var id = "28ca9";
module.get(id, function(err, res) {
console.log(res);
should.not.exist(err);
done();
});
});
});
You can either set the timeout when running your test:
mocha --timeout 15000
Or you can set the timeout for each suite or each test programmatically:
describe('...', function(){
this.timeout(15000);
it('...', function(done){
this.timeout(15000);
setTimeout(done, 15000);
});
});
For more info see the docs.
I find that the "solution" of just increasing the timeouts obscures what's really going on here, which is either
Your code and/or network calls are way too slow (should be sub 100 ms for a good user experience)
The assertions (tests) are failing and something is swallowing the errors before Mocha is able to act on them.
You usually encounter #2 when Mocha doesn't receive assertion errors from a callback. This is caused by some other code swallowing the exception further up the stack. The right way of dealing with this is to fix the code and not swallow the error.
When external code swallows your errors
In case it's a library function that you are unable to modify, you need to catch the assertion error and pass it onto Mocha yourself. You do this by wrapping your assertion callback in a try/catch block and pass any exceptions to the done handler.
it('should not fail', function (done) { // Pass reference here!
i_swallow_errors(function (err, result) {
try { // boilerplate to be able to get the assert failures
assert.ok(true);
assert.equal(result, 'bar');
done();
} catch (error) {
done(error);
}
});
});
This boilerplate can of course be extracted into some utility function to make the test a little more pleasing to the eye:
it('should not fail', function (done) { // Pass reference here!
i_swallow_errors(handleError(done, function (err, result) {
assert.equal(result, 'bar');
}));
});
// reusable boilerplate to be able to get the assert failures
function handleError(done, fn) {
try {
fn();
done();
} catch (error) {
done(error);
}
}
Speeding up network tests
Other than that I suggest you pick up the advice on starting to use test stubs for network calls to make tests pass without having to rely on a functioning network. Using Mocha, Chai and Sinon the tests might look something like this
describe('api tests normally involving network calls', function() {
beforeEach: function () {
this.xhr = sinon.useFakeXMLHttpRequest();
var requests = this.requests = [];
this.xhr.onCreate = function (xhr) {
requests.push(xhr);
};
},
afterEach: function () {
this.xhr.restore();
}
it("should fetch comments from server", function () {
var callback = sinon.spy();
myLib.getCommentsFor("/some/article", callback);
assertEquals(1, this.requests.length);
this.requests[0].respond(200, { "Content-Type": "application/json" },
'[{ "id": 12, "comment": "Hey there" }]');
expect(callback.calledWith([{ id: 12, comment: "Hey there" }])).to.be.true;
});
});
See Sinon's nise docs for more info.
If you are using arrow functions:
it('should do something', async () => {
// do your testing
}).timeout(15000)
A little late but someone can use this in future...You can increase your test timeout by updating scripts in your package.json with the following:
"scripts": {
"test": "test --timeout 10000" //Adjust to a value you need
}
Run your tests using the command test
For me the problem was actually the describe function,
which when provided an arrow function, causes mocha to miss the
timeout, and behave not consistently. (Using ES6)
since no promise was rejected I was getting this error all the time for different tests that were failing inside the describe block
so this how it looks when not working properly:
describe('test', () => {
assert(...)
})
and this works using the anonymous function
describe('test', function() {
assert(...)
})
Hope it helps someone, my configuration for the above:
(nodejs: 8.4.0, npm: 5.3.0, mocha: 3.3.0)
My issue was not sending the response back, so it was hanging. If you are using express make sure that res.send(data), res.json(data) or whatever the api method you wanna use is executed for the route you are testing.
Make sure to resolve/reject the promises used in the test cases, be it spies or stubs make sure they resolve/reject.