Jasmine Headless vs In Browser

In the last couple projects, we’ve been using Jasmine for our Javascript testing. It’s been great. Tying that in with jasmine-headless-webkit has made our Javascript testing super fast for both development and our CI box.

One problem we’ve hit a couple times is differences between the real browser and the fake browser (headless-mode). For example: in the real browser, you can build an iframe with a src attribute and it will do the right thing.

$('body').append(
  $('',
    {src:'http://embedded_page.example.com'})
);

However, if you run this through your headless tests, depending on where this code is executed, you may get errors like this from jQuery:

Fixture could not be loaded: spec/javascripts/fixtures/recipe_subnav.html
(status: error, message: NETWORK_ERR: XMLHttpRequest Exception 101)

or like this from the Jasmine framework:

Can't load file:///projects/myproject/specrunner.11688.html, the file may be broken.
Out of curiosity, did your tests try to submit a form and you haven't prevented that?
Try running your tests in your browser with the Jasmine server and see what happens.

Certainly, we could probably stub out a bunch of stuff to make this fly, but sometimes time is better spent pushing forward. To get around this, we wanted a simple way to check for the command line tests vs in browser tests. We added to our SpecHelper.js file:

var is_headless = function() {
  return (/jasmine-headless-webkit/.test(navigator.userAgent));
};

With this now in place, we can write tests like this:

describe('save scroll top cookie plugin', function() {
  beforeEach(function() {
    loadFixtures('my_fixture.html');
    $('body').scrollTop(123);
    $('#fixture').saveScrollTopCookie();
  });
  if(is_headless()) {
    it('it sets a cookie for scroll position', function() {
      expect($.cookie('scrollTop')).toEqual('123');
    });
  }
  it('does something else', function() {
    expect(somethingElse).toBe(true);
  });
});

With this setup, instead of missing tests because we’ve constructed a bunch of xit or xdescribe blocks, we can keep all the tests around, and simply skip those that don’t lend themselves to the specific situation (in-browser or headless).

It is not something that is used a lot, because we really strive to make tests which are universal, but in those special cases where we still may want a spec, this simple helper method works pretty nicely.

Advertisements

3 thoughts on “Jasmine Headless vs In Browser

    1. On a different project where we’re using Node.js and Jasmine-node, i’ve been looking into getting fakeweb working. It seems like that could (possibly) be a way around it, but i haven’t made enough progress to say for sure. And i’m not sure where one would plug in a ‘fakeweb’ system for the jquery/frontend stuff. If we make headway, we’ll post more info.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s