“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
    - js
    - steps
    - support

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);

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.


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.


Ramble in action

Rails Edge: Getting your view extensions ready for edge

Following my previous post, below is a modified version of “John Nunemaker’s ‘Renaming RHTML to ERB'”:http://railstips.org/2007/3/4/renaming-rhtml-to-erb to take into account the format in the extension, and handle “the RJS issues I was having”:http://www.thelucid.com/articles/2007/05/16/rails-edge-view-file-extention-functionality-has-changed.

namespace 'views' do
  desc 'Renames all .rhtml views to .html.erb, .rjs to .js.rjs, .rxml to .xml.builder and .haml to .html.haml'
  task 'rename' do
    Dir.glob('app/views/**/[^_]*.rhtml').each do |file|
      puts `svn mv #{file} #{file.gsub(/\.rhtml$/, '.html.erb')}`
    Dir.glob('app/views/**/[^_]*.rjs').each do |file|
      puts `svn mv #{file} #{file.gsub(/\.rjs$/, '.js.rjs')}`
    Dir.glob('app/views/**/[^_]*.rxml').each do |file|
      puts `svn mv #{file} #{file.gsub(/\.rxml$/, '.xml.builder')}`

    Dir.glob('app/views/**/[^_]*.haml').each do |file|
      puts `svn mv #{file} #{file.gsub(/\.haml$/, '.html.haml')}`

h4. Update

Added haml conversion.

Rails Edge: View file extention functionality has changed

It seems that on edge revision 6502 and later, the way that view file extensions has changed considerably.

I couldn’t work out why my tests were breaking when doing an xhr request to a new action which had a respond_to block setup for both html and js. It was returning the html instead of the rjs??

It turns out (after tearing my hair out for over three hours) that “Changeset 6499″:http://dev.rubyonrails.org/changeset/6499 changes things in such a way that the normal new.rjs naming will not get picked up on an xhr request, you now need to add the request format to the extension before the template type i.e. new.js.rjs

This seemed a little odd at first but I am guessing it means you could have a new.js.erb file which is pretty cool as you could achieve the same as “Dan Webb’s MinusR plugin”:http://www.danwebb.net/2006/11/17/rjs-minus-r.

What does seem a little odd is that a new.rjs will get picked up if you don’t give a respond_to at-all (I don’t know if this is a “feature” or a bug).

I’m am hoping that this may save someone some time.

Problem: link_to_remote with :method => :delete in Safari

I have just come up against a really frustrating issue with link_to_remote in Safari. What makes it more frustrating is the Rails dev site being down making it impossible to submit a ticket.

When setting :method => :delete on the link_to_remote helper, Safari sends a GET request rather than a DELETE. Firefox is fine with it.

no route found to match "/projects/13;delete" with {:method=>:get}

If anyone knows of a way to fix this I would be most grateful.