I am working on a framework with modules which are loaded asynchronously using promises. These modules contain methods (which, for this question, can be assumed to be synchronous) for which I would like to create tests for.
Currently, my code resembles the following:
describe("StringHelper", function() {
describe("convertToCamelCase()", function() {
it("should convert snake-cased strings to camel-case", function(done) {
Am.Module.load("Util").then(function() {
var StringHelper = Am.Module.get("Util").StringHelper;
//Test here
done();
});
});
});
describe("convertToSnakeCase()", function() {
it("should convert camel-cased strings to snake case.", function(done) {
Am.Module.load("Util").then(function() {
var StringHelper = Am.Module.get("Util").StringHelper;
//Another test here
done();
});
});
});
});
Given that Am.Module.load() is essentially a call to RequireJS wrapped in such a way to return a promise, and hence, should be only loaded once at the beginning, how can I rewrite the above?
I'm essentially hoping to have something like this:
Am.Module.load("Util").then(function() {
var StringHelper = Am.Module.get("Util").StringHelper;
describe("StringHelper", function() {
describe("convertToCamelCase()", function() {
it("should convert snake-cased strings to camel-case", function(done) {
//Test here
done();
});
});
describe("convertToSnakeCase()", function() {
it("should convert camel-cased strings to snake case.", function(done) {
//Another test here
done();
});
});
});
});
Unfortunately, the above does not work - the tests are simply not being executed. The reporter doesn't even display the part for describe("StringHelper"). Interestingly, after playing around, this only occurs if all the tests are written in this (the second code snippet) manner. As long as there is at least one test written in the first format, the tests show up properly.
You can use Mocha's before() hook to load the Util module asynchronously.
describe("StringHelper", function() {
var StringHandler;
before(function(done) {
Am.Module.load("Util").then(function() {
StringHelper = Am.Module.get("Util").StringHelper;
done();
});
});
describe("convertToCamelCase()", function() {
it("should convert snake-cased strings to camel-case", function() {
//Test here
});
});
describe("convertToSnakeCase()", function() {
it("should convert camel-cased strings to snake case.", function() {
//Another test here
});
});
});
Related
How to unit test your code if it's heavily belongs to external library and within each of its methods it calls some external library function.
If everything to mock, than code coverage like Istanbul don't count those lines mocked. Who has experience in unit testing with involvement of external dependencies and libraries, what is the best practice?
For instance, we have 2 internal functions and 3 external library functions.
If mock those external ones, than Istanbul doesn't count those lines as covered.
function internalFoo1(input) {
var result = internalFoo2(input*2);
var finalResult = externalLibraryBar1(result);
return result;
};
function internalFoo2(value) {
var operation = externalLibraryBar2(value*2);
var response = externalLibraryBar3(operation);
return response;
}
How to write a test for internalFoo1() so unit test will cover all its code lines, as well internalFoo2() one.
Ideally you shouldn't be testing external libraries, it's not your job.
In this case, you could just use a spy and see if that library has been called. http://jasmine.github.io/2.2/introduction.html#section-Spies
e.g. taken from Jasmine documentation:
describe("A spy, when configured with an alternate implementation", function() {
var foo, bar, fetchedBar;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
},
getBar: function() {
return bar;
}
};
spyOn(foo, "getBar").and.callFake(function() {
return 1001;
});
foo.setBar(123);
fetchedBar = foo.getBar();
});
it("tracks that the spy was called", function() {
expect(foo.getBar).toHaveBeenCalled();
});
it("should not affect other functions", function() {
expect(bar).toEqual(123);
});
it("when called returns the requested value", function() {
expect(fetchedBar).toEqual(1001);
});
});
Note, related How to test if jQuery 3.0 beta is Promises/A+ compatible in browser?
For example, at promises-tests one of the tests is found at promises-tests/lib/tests/2.1.2.js
"use strict";
var assert = require("assert");
var testFulfilled = require("./helpers/testThreeCases").testFulfilled;
var adapter = global.adapter;
var deferred = adapter.deferred;
var dummy = { dummy: "dummy" }; // we fulfill or reject with this when we don't intend to test against it
describe("2.1.2.1: When fulfilled, a promise: must not transition to any other state.", function () {
testFulfilled(dummy, function (promise, done) {
var onFulfilledCalled = false;
promise.then(function onFulfilled() {
onFulfilledCalled = true;
}, function onRejected() {
assert.strictEqual(onFulfilledCalled, false);
done();
});
setTimeout(done, 100);
});
specify("trying to fulfill then immediately reject", function (done) {
var d = deferred();
var onFulfilledCalled = false;
d.promise.then(function onFulfilled() {
onFulfilledCalled = true;
}, function onRejected() {
assert.strictEqual(onFulfilledCalled, false);
done();
});
d.resolve(dummy);
d.reject(dummy);
setTimeout(done, 100);
});
specify("trying to fulfill then reject, delayed", function (done) {
var d = deferred();
var onFulfilledCalled = false;
d.promise.then(function onFulfilled() {
onFulfilledCalled = true;
}, function onRejected() {
assert.strictEqual(onFulfilledCalled, false);
done();
});
setTimeout(function () {
d.resolve(dummy);
d.reject(dummy);
}, 50);
setTimeout(done, 100);
});
specify("trying to fulfill immediately then reject delayed", function (done) {
var d = deferred();
var onFulfilledCalled = false;
d.promise.then(function onFulfilled() {
onFulfilledCalled = true;
}, function onRejected() {
assert.strictEqual(onFulfilledCalled, false);
done();
});
d.resolve(dummy);
setTimeout(function () {
d.reject(dummy);
}, 50);
setTimeout(done, 100);
});
});
Requirement:
The ability to run the test in the browser without reliance on node.js , a server, or installing libraries?
Question:
How can this test be converted to a version using native methods available at browsers, for example Console methods; that is, substitution of console.assert() or other native method available at window for describe() and specify()?
I still think this is a terrible idea, but here's a (trivial) example:
var assert = {};
assert.equals = function(expected, value, msg) {
var message = msg || "Test ";
try {
expected == value;
console.log(message, "passed");
catch (e) {
console.log(message, "failed", e);
}
};
Now repeat for >, <, ===, ranges, exceptions when they're expected, specific exceptions (e.g. TypeError, SyntaxError), typeof, instanceof, other types (built-ins, constructed), problematic values like NaN and null, etc.
NOTE: console.assert
There are some problems with console.assert. First, its non-standard and may not behave identically across platforms. Second, there is, AFAIK, no good way to abstract it: you'd end up doing just as much work as the above solution using console.log unless you use eval and string arguments:
function assert(str, msg) {
try {
console.assert(eval(str), msg);
catch (e) {
console.log(msg, " failed:", e);
}
}
assert("3 === 4", "Three equals four"); // logs the assertion failure.
Needless to say, I do not recommend this, as manually constructing the strings is error-prone, eval (even though safe in this case) is a notorious perf killer, and not using eval means using a parser and bam we're right back to the library bit.
Seriously, as you go down this road you will think of more and more things you want to be in there (see my list above) and you will realize you are writing a library when you could have used one.
UPDATE
Per your question in the comments below, many testing libraries (e.g. mocha, jasmine) use a format like this:
wrapper('name of the thing being tested', function(done) {
innerWrapper('description of the test', function(done) {
assert(someAssertion);
});
innerWrapper('some other test for that function', function(done) {
assert(somethingElse);
someAsyncFunction().then(function(value) {
assert(somethingAboutValue);
done();
});
});
});
The 'wrapper', 'innerWrapper', and 'assert' are added by including the testing library in the code or running the command (for cli) i.e. 'mocha tests.js' instead of 'node tests.js'. The setup may or may not use the inner functions to specify subtests. 'Done' is an argument to the callback that can be used to signal the end of an async test.
QUnit is a little simpler in its API, but not too far off.
UPDATE 2
Those for the most part are names for the same things: functions that wrap a test condition to make sure that correct messages are logged, or exceptions caught, or async gets a chance to finish. The assert tests the actual condition to be evaluated. The adapter reference means wrapping the jQuery deferred constructor to match the API in the spec.
It appears that sinon.spy(object, method) is not wrapping my object#method as expected.
(I have an uneasy feeling that I'm seeing the same problem as described here and here, but I don't see why this should be. I've instantiated my object before calling sinon.spy(...), and AFAIK I'm not using any cached objects.)
Here's the complete test file:
var
AmbitParser = require('../lib/parsers/ambit-parser'),
expect = require('chai').expect,
sinon = require('sinon');
describe('AmbitParser', function() {
var ambit_parser = new AmbitParser();
describe('#extractLineItems()', function() {
it('calls extractLineItems once', function(done) {
var spy = sinon.spy(ambit_parser, 'extractLineItems');
ambit_parser.parseBills(function gotBills(err, bills) {
expect(ambit_parser.extractLineItems.callCount).to.equal(1); // => expected undefined to equal 1
expect(spy.callCount).to.equal(1); // => expected 0 to equal 1
done();
});
ambit_parser.extractLineItems.restore();
}); // calls extractLineItems once
}); // #extractLineItems
}); // AmbitParser
The call to expect(ambit_parser.extractLineItems.callCount).to.equal(1); results in 'expected undefined to equal 1' and if I change that to expect(spy.callCount).to.equal(1);, I get 'expected 0 to equal 1'.
Together, this makes me think that the call to sinon.spy(...) is not wrapping the ambit_parser.extractLineItems method as expected, but I can't see why this is the case.
The problem is the placement of the call to restore(): it should not be in the body of the test function. Instead, put it in an after() block.
What's happening is that the restore() method is getting called immediately after the test is started, so by the time the callback is executed, the spied upon method has been restored, so sinon will report that the method has never been called.
The following modifications to the original code will work as expected:
describe('AmbitParser', function() {
var ambit_parser = new AmbitParser();
describe('#extractLineItems()', function() {
before(function() {
sinon.spy(ambit_parser, 'extractLineItems');
});
after(function() {
ambit_parser.extractLineItems.restore();
});
it('calls extractLineItems once', function(done) {
ambit_parser.parseBills(function gotBills(err, bills) {
expect(ambit_parser.extractLineItems.callCount).to.equal(1);
done();
});
}); // calls extractLineItems once
}); // #extractLineItems
}); // AmbitParser
Moral of the story: make sure you call reset() only after any callbacks have completed.
I'm trying to write a plugin for Jasmine that allows you to return a promise from a spec and will pass or fail that spec depending on whether or not the promise is fulfilled or rejected.
Of course, I want to write tests to make sure that my plugin works correctly, and to be thorough, I need to make sure that tests fail when the promise is rejected... so how do I make a test pass when I need to make sure that a test "successfully fails"?
After a conversation with the developers who work on Jasmine, we've come up with this:
var FAILED = 'failed'
var PASSED = 'passed'
describe('My Test Suite', function () {
var env
beforeEach(function () {
// Create a secondary Jasmine environment to run your sub-specs in
env = new jasmine.Env()
})
it('should work synchronously', function () {
var spec
// use the methods on `env` rather than the global ones for sub-specs
// (describe, it, expect, beforeEach, etc)
env.describe('faux suite', function () {
spec = env.it('faux test', function (done) {
env.expect(true).toBe(true)
})
})
// this will fire off the specs in the secondary environment
env.execute()
// put your expectations here if the sub-spec is synchronous
// `spec.result` has the status information we need
expect(spec.result.status).toBe(FAILED)
})
// don't forget the `done` argument for asynchronous specs
it('should work asynchronously', function (done) {
var spec
// use the methods on `env` rather than the global ones.
env.describe('faux suite', function () {
// `it` returns a spec object that we can use later
spec = env.it('faux test', function (done) {
Promise.reject("FAIL").then(done)
})
})
// this allows us to run code after we know the spec has finished
env.addReporter({jasmineDone: function() {
// put your expectations in here if the sub-spec is asynchronous
// `spec.result` has the status information we need
expect(spec.result.status).toBe(FAILED)
// this is how Jasmine knows you've completed something asynchronous
// you need to add it as an argument to the main `it` call above
done()
}})
// this will fire off the specs in the secondary environment
env.execute()
})
})
Going off Joe's answer, I moved the fake test context into a single function. Since the code under test is making use of jasmine expectations, I load the inner Env into jasmine.currentEnv_ and call it explicitly with jasmine.currentEnv_.expect(). Note that currentEnv_ is an internal variable set by jasmine itself, so I can't guarantee that this won't be broken in a future jasmine version.
function internalTest(testFunc) {
var outerEnvironment = jasmine.currentEnv_;
var env = new jasmine.Env();
jasmine.currentEnv_ = env;
var spec;
env.describe("fake suite", function () {
spec = env.it("fake test", function () {
func();
});
});
env.execute();
jasmine.currentEnv_ = outerEnvironment;
return spec.result;
}
Then each test looks like
it("does something", function () {
//Arrange
//Act
var result = internalTest(function () {
//Perform action
});
//Assert
expect(result.status).toBe("failed"); //Or "success"
expect(result.failedExpectations.length).toBe(1);
expect(result.failedExpectations[0].message).toBe("My expected error message");
});
When working with Jasmine testing framework, I have come across a code snippet where expect is written in a sub-function which is called in it(), but not in it() itself. The reason behind writing this is, they were trying to compare similar objects and they refactored test code and moved this expect to the sub-function. Now, we don't have expect in it() rather we have a method call which has expect.
describe("bla bla", function() { //for nunit, junit guys, this is testSuite()
function somefunc() { //this is [test]
//do some stuff and generate object
expect(someObject).toEqual(otherObject); //expect is assert
}
it("some case", function() {
//do some stuff
somefunc();
});
it("some other case", function() {
//do some other stuff
somefunc();
});
});
Now, is this kind of test code encouragable? can we have it() without expect ?
I would argue that the two examples below are both readable. If assertExpected() did some kind of setup for otherObject the first example could be more readable.
describe("bla bla", function() { //for nunit, junit guys, this is testSuite()
function assertExpected() { //this is [test]
//do some stuff and generate object
expect(someObject).toEqual(otherObject); //expect is assert
}
it("some case", function() {
// Arrange
var someObject;
// Act
someObject = testMethod('foo');
// Assert
assertExpected();
});
it("some other case", function() {
// Arrange
var otherObject, someObject = testMethod('foo');
// Act
someObject = testMethod('foo');
// Assert
assert(someObject(foo)).toEqual(otherObject);
});
});
I think the deciding factor here should be deciding on a house style and sticking with it. There's no clear winner here and this question probably isn't a good question for SO.