Data driven JavaScript tests using Jasmine

In my previous post I introduced Jasmine as a tool for testing JavaScript code. Now that I’ve had some more time to play around with it, combining it with Protractor for user interface-driven tests for one of my client’s websites, I’ve noticed that one feature was sorely missing: built-in support for data driven testing. All BDD tools (or tools that say they support BDD) that I have worked with so far, such as Cucumber, SpecFlow and JGiven, support the creation of data driven scenarios. However, Jasmine doesn’t, at least not as far as I have seen in the limited time I have been using it so far.

As I think data driven testing is key when creating maintainable and reusable scenarios, I fired up Google to check whether someone had already found a solution. From what I’ve read, there are (at least) two different ways to do data-driven testing with Jasmine. Let’s have a look at both.

Specifying your test data in an array variable
I found the first approach in the comments of this StackOverflow post. The comment submitted by peterhendrick suggests the use of a JSON file containing the test data. I slightly simplified this to use a simple array of key-value pairs and have the Jasmine spec loop through the array. You can simply populate this array any way you like, for example from an external .json file as suggested, but in any other way as well. In this example, I hard-coded it in the spec itself:

describe("Calculator (data driven tests with test data specified in array)", function() {
  var calc;
  var testdata = [{"x":1,"y":1,"sum":2},{"x":2,"y":3,"sum":5},{"x":4,"y":2,"sum":6}];
  beforeEach(function() {
    calc = new Calculator();

	for(var i in testdata) {
		it("should be able to add two numbers, using (" + testdata[i].x + "," + testdata[i].y + "," + testdata[i].sum + ")", function() {
			expect(calc.add(testdata[i].x, testdata[i].y)).toEqual(testdata[i].sum);

I particularly like this example because it enables you to add the actual values used to the test output. You can see this when you run your spec:

Test results from driving test data through an array

Data driven testing with a custom using function
This blog post from JP Castro presents an alternative way to do data driven testing in Jasmine. His solution seemed easy enough for me to apply directly to my own specs. Let’s see what it looks like.

The basic idea behind his solution is to wrap each it block in a spec with a using block that passes the parameter values to the it block:

describe("Calculator (data driven tests with using() function)", function() {
  var calc;
  beforeEach(function() {
    calc = new Calculator();

  using('parameters',[[1,1,2],[2,3,5],[4,2,6]], function(parameters){
	it("should be able to add two numbers, using (" + parameters[0] + "," + parameters[1] + "," + parameters[2] + ")", function() {

The using function he presents is implemented as follows:

function using(name, values, func) {
	for(var i = 0, count = values.length; i < count; i++) {
		if([i]) !== '[Object Array]') {
			values[i] = [values[i]];

When we run the spec above, the output looks like this:

Test results from driving test data through a using function

So, now we have two simple (and admittedly similar) workarounds for what I think is still a fundamental shortcoming in Jasmine. The code demonstrated in this blog post can be downloaded here.

14 thoughts on “Data driven JavaScript tests using Jasmine

  1. Pingback: Testing Bits – 4/24/16 – 4/30/16 | Testing Curator Blog

  2. Hi Bas,

    Great Post!!!
    In protractor with Jasmine framework, any way to do data driven testing from an external file such as Excel?

    • Googling for ‘jasmine data driven’ I found some node.js packages that allow you to create data driven tests. None of them are specifically targeted towards Excel, though, but I saw something that uses .csv, I think. Feel free to explore.

    • Good point. It’s been a while since I worked with tools for automated tests in the JavaScript ecosystem, but maybe one of my readers can help you out with this..

    • I have no idea. Never worked with TypeScript. Are there even libraries available for TypeScript that allow you to read Office documents? Also, you might want to reconsider using such an approach in the first place. Not too fond of using Excel (or any other type of Office) documents in automation solutions.

  3. I’m getting inconsistent results in the for loop variation for some reason. Though the second variation is working just fine. I just have a data set of two objects with three members each. Nothing too complicated. I’ve gone over it with a fine toothed comb to see if its an error on my side, but it seems not to be.

    It’s weird. I have the two data set objects and I get two errors. I delete one of them and I get zero errors. It’s not logically working the way it should. I should still have one error. It’s like values are bleeding between the for loop or something. Closures maybe? I don’t know. I don’t know enough about them.

    Thought I’d bring it up just in case someone else has the same problem.

  4. I agree with Evan as I have spent a couple of hours finding out why the test behaved differently.
    Spolier: I did not find out.

    I remove dependencies as much as I could. I called in a human rubber duck. I ran locally an on the build server.

    In the end it looked like the `expect` were all executed, disregarding failure/success and were called in an order we could not understand.
    They also failed when they shouldn’t.

    When I ran the test by itself it always succeeded.
    Run with other tests the outcome depended on, for instance, how many `expect` I had in other tests.
    I had 2 quite similar tests and one ran fine and one not. When I introduced more `expect` they could both fail.

    The best, still bad, guess I have is that `foreach` is overloaded in Jasmine? and has introduced a weird behaviour. No, I do believe it as but in lack of better guesses.
    Or something with `expect` that messes up the separation of tests.
    Or something else.

    I have not something for anyone to play with as… as… as… I rewrote the tests and moved on. Unfortunately.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.