I admit it. I put off using Cucumber for a few years while it became more stable. I took a look at it a few years ago and found it didn’t really work properly according to the then current documentation. So, I shelved it until recently. There seems a renewed interest in BDD and Cucumber recently so I decided to take another look. Needless to say, I was impressed and since I was starting a new project I figured it was the perfect time to start using Cucumber.

An hour or so into it, I still didn’t have my first test passing but I felt I was making progress so I persisted. Here is my first test:

I added the ‘@javascript’ part later. I couldn’t figure out why my AJAX query wasn’t running in Cucumber. It was working fine in my browser so I asked my buddy Corey. He pointed me to Capybara.

Basically, there are 2 distinct pieces to the testing process in Cucumber.

1. the step definitions
2. the browser simulator

For the step definitions part, its not really about you write the steps but more about how those steps are translated back to the DOM and how they interface with the browser simulator. Cucumber uses Webrat as the default for step definitions and I may have just followed the introduction docs to end up with that as the default. The problem with Webrat is that it doesn’t support interfacing with the DOM very well and so it doesn’t allow access to page elements that have been updated by Javascript. That means any AJAX testing is completely out the window. Unfortunately, most websites today pretty much require Javascript so Webrat is pretty much useless to me.

Capybara is a Webrat alternative that does support Javascript. Capybara allows you to access DOM elements that have been updated by Javascript. Now here’s where things get tricky. Both Webrat and Capybara integrate with Selenium, a browser simulator. The same simulator is being run in both cases but only Capybara has the ability to access the updated DOM elements.

This allowed me to finish up my first test. I didn’t notice it at first but after I added a second test I realized how slowly these tests were running. I didn’t get any quantitative performance data to share but just sitting there waiting for 2 simple tests to run I was pretty amazed that anyone would even be testing like this. There would be no way this could scale to a suite of tests for an entire site. The time wasted in just waiting for all the tests to run would prevent any actual development to occur.

So I started looking for alternatives. The culprit in the slowdown here was Selenium. I came across a blog post by RubyFlare the was talking about a much faster alternative to Selenium called envjs. You need to install the capybara-envjs gem, the envjs gem, and reconfigure some things in Cucumber but its fairly simple.

Now that I had my brand new envjs browser simulator working with Cucumber and Capybara, I tried to run my first 2 tests on it. FAILED

What I discovered in the envjs output was:

ERROR: [Sun Jul 04 2010 17:44:10 GMT-0600 (CST)] {ENVJS} response XML does not apear to be well formed xml Line: 1377
ERROR: [Sun Jul 04 2010 17:44:10 GMT-0600 (CST)] {ENVJS} ReferenceError: $domparser is not defined


I started digging through the envjs code and basically discovered it doesn’t really support AJAX calls returning HTML. Just XML. Well back to the drawing board. It doesn’t seem like it would be incredibly difficult to add support for that to envjs and the rest of the chain of libraries up to Cucumber. When? I’m not going to start responding to all my AJAX queries with well formed XML instead of simple HTML anytime soon. It would just add an unnecessary layer of complexity to the application and I would have to do it just to use the envjs browser. No thanks. Back to the drawing board.

Since I did get my first AJAX tests to pass using Selenium, I reverted back to using that so I can at least progress for now, albeit slowly. I know a lot of people are frustrated by the slowness of Selenium so I doubt it’ll be too long before envjs supports HTML to be returned from AJAX calls.