You may be asking yourself why you’d want to do this in the first place. Well here’s why I would want to do it.
We had some Webdriver based Cucumber tests that passed fine locally but kept failing on our CI box. Our CI box is a bit underpowered at the moment so I thought what might be happening is that our tests weren’t waiting long enough for the Ajaxy stuff to happen because the Ajax responses were taking a long time.
After some poking around in the source code of jQuery, I found the $.active property. This property keeps track of the number of active Ajax requests that are going on and I thought this might help us out.
What I came up with was this gist:
I added this step right after my Cucumber step that caused the Ajax call so that Cucumber would wait to move on until I knew that everything was done.
This step solved our CI failures and all was good in our test suite again.
Forget the steps I published earlier…just install the capybara-firebug gem and away you go.
SauceLabs is a cloud based way to test your site against different browsers.
Up until now, they only supported the older Selenium RC based tests.
For those of us using Capybara, we were out of luck because Capybara uses Webdriver.
Well that just changed, they now support Webdriver. Check out the instructions on how to get is set up here.
The one thing that I disagree with in that post is setting the default Capybara driver to :sauce (Capybara.default_driver = :sauce). This seems a little heavy handed to me since I may not want to run all of my scenarios through the Sauce driver.
Upon further review of the source code, it looks like after installing the sauce gem, they redirect any scenarios tagged with @selenium to the Sauce driver. I like this better so if you don’t want to switch over all of your scenarios over to Sauce, you can just ignore the line mentioned above and simply tag the scenarios you want to run on Sauce with @selenium.
I haven’t had a lot of time to play with this but at least it is a start in getting Capybara based Cucumber scenarios to run against Sauce Labs.
My next step is to figure out how to run one Cucumber scenario to run against multiple browsers on Sauce.
Another thing I’d like to figure out how to do is only run Selenium based tests on demand so they don’t run on Sauce every time I run my Cucumber suite. That could run up a decent Sauce bill, especially if you had multiple developers running Cucumber scenarios multiple times a day.
While helping client upgrade a Rails 2.3.10 site to Rails 3.0.1, I came across a very perplexing problem with our WebDriver based Cucumber tests that all worked fine under 2.3.10.
We were “randomly” getting some very strange errors from Cucumber having to do with timeout problems and other strangeness like Cucumber not being able to find form fields to fill in.
1) require => false for the FakeWeb line in the Gemfile
2) add require ‘fakeweb’ to the top of the test_helper.rb file
or optionally scrap FakeWeb for either Artifice or WebMock
It has something to do with FakeWeb inserting it into the HTTP stack strangely even if you tell it to allow non-local HTTP requests. We weren’t seeing it in 2.3.10 because we were using a cucumber environment to run the cucumber tests. Now under 3.0.1 we run the cucumber tests in the test environment.
I wish I had some more details but I was just happy to move past this strangeness so I didn’t really look back.
Ever wanted to be able to debug an HTML page using the power of Firebug while running Cucumber/Capybara features/steps?
Follow these simple steps and you can get it to work:
1) Create a new “WebDriver” Firefox profile using the instructions found here
2) Fire up Firefox using the newly created profile and install/configure Firebug the way you want it. See instructions above.
3) Run your Cucumber/Capybara steps and pause the feature using a sleep() statement long enough for you to poke around in the page with Firebug.
**Note this has been proven to work on OS X, your mileage on other OS’s may be limited.