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.
If you haven’t looked at OmniAuth for authentication with sites like Google, Github and Facebook, then you should take a look. It is pretty killer.
This morning we needed to write a Cucumber scenario to test that a user could log into the system using Google Apps.
We did a quick spike on getting OminAuth integrated, which was a super simple process, and poked around in the browser to make sure it was working OK.
Thanks to Jose Valim for providing some guidance, via the Devise test suite, on how to get this all up and running.
The basics can be found in this Gist:
I put that code in /features/support/omniauth.rb and then all I need to do is label any scenarios that need to deal with login with an @omniauth_test tag and we are all set.
As our features count grows, I could see us doing this before/after all Cucumber scenarios.
Note: You need to be using 0.2.0.beta5 of OmniAuth to get this to work. Earlier versions don’t have the testing functionality built in.
Also Note: This same functionality can be used in good, old RSpec integration tests or Steak tests as well.
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.
So I’ve been doing a bunch of BDD development these days using Cucumber as a starting point.
While working with client, the question came up about how they could share step definitions across multiple teams of developers.
I then remembered that the Aruba gem is just that, a collection of Cucumber step definitions.
So if you are looking for a way to start packaging up those step definitions that you have used on multiple projects and are tired of copying across projects, check out how the Aruba gem does it and go from there.
Thanks to the Cucumber and Aruba folks for sharing some very useful technology that allows us all to raise the bar when it comes to delivering quality software.
In an effort to continue my contributions to the open source Ruby/Rails ecosystem, I decided to help the factory_girl_rails team move the Rails3 generators from the rails3-generators project into the factory_girl_rails project.
Like all good Ruby/Rails developers, they asked to make sure that I had tests written around the generators. I thought for a bit on how I was going to do this and then I wandered across the Cucumber feature files in the rspec-rails repo and found my answer.
Rspec-rails (and RSpec2 as well) uses a gem called Aruba to easily write Cucumber features around things that happen from the command line.
If you’d like to check out the result of using Cucumber and Aruba to test Rails3 generators, head over to my fork of the factory_girl_rails gem and check out the features/generators.feature file.
Hopefully the changes will be merged into the official factory_girl_rails repo soon and the generators will live closer to home.
In continuing with my Cucumber themed posts, here is a great post about using Cucumber and Sunspot together…
The has_css? method call will wait until the element shows up and if it doesn’t show up before the Capybara timeout expires then it will return false.
For some reason the Universe keeps sending great Cucumber related stories to me via Twitter.
Here is another great one from the folks at Square on how to test Resque based functionality via Cucumber:
Try adding the following to your Gemfile:
gem 'thin', :group => :test
and see what happens.