Good. Evil. Bratwurst.

What I Did To The Jasmine Phantom

Posted on by arlen

Being a continuation of the saga began in Jasmine And The Headless Webkit.

OK, after the last installment I had a working in-browser test runner (standalone Jasmine) and a working command-line test runner (phantom-jasmine). But they were different files, meaning if anything significant changed, I was going to have to duplicate the changes in two different testing files. This, while workable short-term, is not an acceptable solution.

So I dug in to the files.

Upon examination, the browser runner that came with standalone Jasmine included the exact same jasmine files that the command-line runner that came with phantom-jasmine included, so I could dispense with those. But the reporters were different.

The standalone Jasmine used the HTMLReporter from jasmine-html.js, but that reporter wouldn’t cut it from the command line. And phantom-jasmine used a custom-written ConsoleReporter that wasn’t included at all in standalone Jasmine.

So I had some reconciliation to do. I revised the testing script in my testrunner file (I used the standalone Jasmine specrunner.html as my base file, because it already included most of what I wanted it to be) and revised the test script in it to be:

  var console_reporter = new jasmine.ConsoleReporter()
  var htmlReporter = new jasmine.HtmlReporter();
  var jasmineEnv = jasmine.getEnv();
  jasmineEnv.specFilter = function(spec) {
	return htmlReporter.specFilter(spec);
      var currentWindowOnload = window.onload;

      window.onload = function() {
        if (currentWindowOnload) {

      function execJasmine() {

Originally, phantom-jasmine used the TrivialReporter, but that’s marked as deprecated currently, with the HTMLReporter suggested as the replacement for it, making this easy, because the specrunner file already used it.

Then I moved the ConsoleReporter javascript file into a “vendor” directory in my jasmine directory and added a <script> tag to point at its new location. Voila! The tests now ran from either source. A single file ran the same tests either from the command-line or the browser.

I mentioned I’d been using the command-line to run the tests for a while, and while I had been developing with it I noticed the reporting from it wasn’t what I’d like it to be. So I dug into more of the code.

Everything I needed to change was in the method “reportSuiteResults.” Originally it read:

  proto.reportSuiteResults = function(suite) {
    if (!suite.parentSuite) { return; }
    var results = suite.results();
    var failed = results.totalCount - results.passedCount;
    var color = (failed > 0)? "red" : "green";
    this.log(suite.description + ": " + results.passedCount + " of " + results.totalCount + " passed.", color);

Note this completely skips reporting on the top level of describe blocks, so while you may know a little of what you’re testing, you don’t know the full context. Plus, if you had a series of tests that were at the top describe level, the results weren’t reported by this code. Not Good.

So I revised the code to be this:

  proto.reportSuiteResults = function(suite) {
    var results = suite.results();
    var failed = results.totalCount - results.passedCount;
    var color = (failed > 0)? "red" : "green";
    var mySuite = suite;
    var description = suite.description;
    while (mySuite.parentSuite) {
        mySuite = mySuite.parentSuite;
        description = mySuite.description + " " + description;
    if (!suite.parentSuite) {
        this.log("-- " + description + " spec subtotals: " +
            results.passedCount + " of " + results.totalCount + " passed.",
    } else {
        this.log(description + ": " + results.passedCount + " of " +
            results.totalCount + " passed.", color);

This starts out pretty much the same as the original code. But it captures the describe blocks at every level, including the top, and concatenates them into one long sentence. It then creates either a subtotal line for an outer describe block or a results line for the inner describe block. This change helps me more easily find which tests ran fine and which ones didn’t.

I’m not sure this is the exact thing I’m looking for in this reporter, yet, but it’ll do for now. And hopefully I’ve given you some ideas for customizing the Jasmine reporters yourself. Let me know if you find some interesting things to do in them.

Leave a Reply

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

September 2012
« Nov   Oct »