“Ramble”, the Javascript Cucumber Port (work in progress)

I am a great fan of Cucumber when it comes to integration testing, however testing heavy use of Javascript can be a little tedious.

I have looked into the different solutions out there such as Selenium but found them all to be fiddly to setup, however Capybara helps on this front. I was thinking, what if Cucumber could run in the browser? No need for Javascript adapters or XML parsers, Safari/Chrome/Firefox already do a great job of this. Manipulating the page such as filling in forms, clicking links etc. could all be done with jQuery, in a very concise manor.

I decided to create a proof-of-concept while it was still fresh in my head. This is by no means a fully working release and the code leaves a lot to be desired in it’s current state, however it shows the benefits of a “Cucumber in the browser”. The main benefits I can see so far (for both javascript and non javascript apps) are:

  • Speed – browsers are getting extremely quick at this DOM stuff.
  • Flexibility – everything happens client-side meaning you can easily test with any server technology.
  • Simplicity – no need for complex javascript adapters, XML parsers etc.

The basic file structure is very similar to Cucumber:

  - features
    index.html
    - js
        ramble.js
        jquery-1.4.2.js
      my.feature
    - steps
        web-steps.js
    - support
        paths.js

Step definitions can be defined in plain old javascript files with plain old jQuery, in this case web-steps.js. Currently the step definition are expected to throw an error if they cannot be fulfilled, this may change when a solid API is nailed down:


  // The value of 'this' is the current document as a jQuery object.
  ramble.match(/^I follow "(.+)"$/, function(link_text) {
    var link = this.find('a').filter(function() { return $(this).text() == link_text; });
    if(!link.length) throw("Can't find link: " + link_text);
    link.click();
  });

Scenarios are exactly the same as in Cucumber, so you can do something like the following:

  Scenario: User fill out a form
    Given I am on the homepage
    And I follow "Tell us your name"
    And I fill in "First name" with "Jamie"
    And I fill in "Last name" with "Hill"
    And I press "Submit"
    Then I should see "Thank you for your details."

You can now simply drop the features folder into the public area of your app and visit the url in your browser. You should see the relevant steps go green or red as the app is navigated in an iFrame.

I plan to first tidy up the API (and unit test) and then aid the writing of scenarios by adding the ability to record them within the browser (Selenium style).

I’d like to hear peoples views on this… please don’t be too hard on the code, it’s more of a mind-dump than anything else at this stage (around 100 lines). There is an example of testing a static site included so just load the features/index.html file in your browser to see it run.

http://github.com/soniciq/ramble

Update 04/07/10: As noted by Andrew in the comments, you will need a server running in order for browsers to get access to the pages for testing.

I have added a simple server script allowing the features to be run locally (requires Ruby). If you want to see it in action, just run:

cd /path/to/ramble/checkout
ruby server.rb

…and then visit http://localhost:1234/features in your browser (tested in Firefox, Chrome and Safari). Note that Ramble is not at all dependent on Ruby, it is just used for running a local test server.

Screenshot

Ramble in action

Published by

Jamie

Hi, I am the Managing Director of SonicIQ Limited in the UK. I have been working in the web development industry since 1999 and have been running SonicIQ since 2001. Currently Ruby On Rails is my preferred development platform. I am experienced in designing with web standards, HTML5, CSS3 and Javascript.

6 thoughts on ““Ramble”, the Javascript Cucumber Port (work in progress)”

  1. It runs locally in Safari on OSX and I’m just looking into why this isn’t the case with Chrome. Did it report any errors in the Javascript console?

  2. No, but if I use a raw XMLHTTPRequest object and do any local requests manually, it basically spits out a network error and sets the return data to an empty string and the status code to zero.

    I think it’s probably a browser issue you wont be able to work around, a case of Chrome’s security sandbox being a bit overzealous, considering the request originating from the local filesystem, you’d think it’d allow requests back there, but apparently not.

  3. Very cool stuff. And I really like the simplicity of it (compared to the various stacks used to drive the already complex Selenium).

    I’ve always found driven mode a bit curious, not the least since Selenium Core itself is a competent js-based client engine. Minimizing the server role to just serve files, solve XDR and perhaps receive spec results (for e.g. CI scenarios) seems more reasonable.

    (The thing I did about it at the time (some years ago) was to write a text-to-selenese utility: http://neverspace.net/development/plaintext2selenese/index.html (often used with Selenium RC w/o driven stuff). I haven’t really taken it anywhere after that though.)

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>