Implementing Testing for Popcorn Maker

For the foreseeable future my main focus is going to be beefing up the testing system in place for Popcorn Maker. As it stands Popcorn Maker doesn’t have the same sort of testing environment and infrastructure that Popcorn.js has and this needs to be changed. Some basic QUnit based tests are present however they are never run and most are severely out dated, basing themselves off of an older version of the Butter SDK behind all of this. This is due to the culture the project currently has and my goal is to be apart of the change behind it.

All the Areas that Need Testing

  • Comm
  • Dialog
  • EventEditor
  • Cornfield
  • PluginManager
  • Timeline
  • TrackEditor
  • UI Testing
  • Test Harness so all the above testing can be run easily all at once

Needless to say, it’s a long list. A lot of it involves areas of the Butter SDK that I don’t know much about. On top of that there doesn’t seem to this one framework that can handle everything we want to do on the UI Testing side all nice and neatly like QUnit does for everything else. I have played around with Selenium a lot and that proved to be quite the nightmare. I’m still not 100% certain if it’s what we want to use because there are definitely elements to it that work and a lot that seemingly don’t. Right now I’m playing around with two frameworks, called PhantomJS and CasperJS, which CasperJS is built on top of PhantomJS to provide additional functionality.

As it stands, CasperJS doesn’t appear to allow me to send key events in any way to the page it interacts with. This is bad because it basically means I can’t run any of our tests that rely on some sort of key press from the user. On top of that there doesn’t appear to be anything available to test dragging and dropping of elements on a page. Once again, this is also a problem because we wouldn’t be able to test moving things like track events, track containers, track handles, events onto a track and anything else I haven’t included.

Thusfar I have only been able to have these run on the command line. I’m sure there is some sort of way that to integrate all of this together, so I went and asked their google group to see if someone more knowledgeable can assist me. In the mean time, here is some of what I have come up with thusfar:


casper.test.comment( "Testing iFrame Dialog Closing with Esc Key - Popcorn Maker" );

var p = require("webpage").create,
    t = Date.now();

casper.start( "http://localhost:8888/templates/test.html", function(){

  t = Date.now() - t;

  console.log( "Loading Time: " + t + "msec" );

  // Ensure template has loaded
  this.waitUntilVisible( "#butter-header-new", function(){

    // Confirm button exists
    this.test.assertExists( "#butter-header-new", "The button did load" );

    // Move mouse over button
    this.mouse.move( "#butter-header-new" );
    // Click zee button
    this.click( "#butter-header-new" );

  });

});

casper.then( function(){

  // Our iFrames don't have IDs, but all use the same class and this class is
  // only ever present in the DOM once
  this.test.assertExists( "iframe[class=' fade-in']", "The iFrame Loaded" );

});

// Run the whole test suite (all the above)
casper.run( function(){

  // Sends a test done message when all the of the above has finished running
  this.test.done();
  this.test.renderResults( true, 0, "iframe_esc_close.xml" );

});

This set of tests opens our testing template and then wait’s for our content to load. Once it has, it ensures an element with the id butter-header-new is present in the DOM. It then moves the mouse of that element, and clicks it. After the click has finished it will check if an iFrame with the class name fade-in is present. All of our iFrame dialogs use this class name and there will only ever be one iFrame dialog open at one time.

One of the interesting things that is run after all the tests are done is Casper.renderResults. What it does is send the results of our testing to the file I specified in an XUnit formatted XML file. From what I read we might be able to hook this into another continuous integration service such as Jenkins.

Here’s what running that code looks like:

What’s next?
Hopefully we can sort this out sooner rather than later. Once we can solve exactly what frameworks/technologies we will use to write out tests we can actually go about and well, write them! Hopefully my next post will include some of that :)

Until then!

About these ads

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

Follow

Get every new post delivered to your Inbox.

Join 117 other followers

%d bloggers like this: