OAuth providers like LinkedIn often pop-up in a new browser window rather than in Javascript so that the user entering their credentials can see the location bar to be sure they are not being phished by the website requesting their credentials. This is great for security, but not so great for Cucumber testing.
features/signup.feature
Scenario: Sign Up with LinkedIn
When I go to the home page
And I follow "Sign Up"
And I grant LinkedIn access
Then I should be on the new user page
My application has a hyperlink that opens the OAuth login on the OAuth provider's website in a new window. Let's presume the simple matter of wiring this up is already coded in my view.
Testing this with Cucumber requires telling the Selenium web driver to interact with the new popup window. We can do this using page.driver.browser.window_handles to find the newest window handle and scoping out actions to that window.
features/support/signup_steps.rb
When /^I grant LinkedIn access$/ do
begin
main, popup = page.driver.browser.window_handles
within_window(popup) do
fill_in("Email", :with => "newlee@pivotallabs.com")
fill_in("Password", :with => "password")
click_on("Ok, I'll Allow It")
end
rescue
end
end
And that's it!
Keep in mind that if you use this test as-is, you will be hitting LinkedIn on the real Internet. This is great if you want a test that will always verify the real API, but not so good for CI, since it is Internet connection-dependent and slow. Consider using something like VCR or Artifice to stub out your service calls.
Needful Things; Help
- How to test command line applications? Use the old stand-by, expect, patch into the highline library, or the new hotness, aruba (CLI steps for Cucumber).
Very Interesting Things
- fbAsyncInit does not fire when Facebook is really ready, only kind of sorta, maybe ready.
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.
Interesting Things
- Project Sprouts from Luke Bayes "an open-source, cross-platform project generation and configuration tool for ActionScript 2, ActionScript 3, Adobe AIR Flash and Flex projects"
"Project Sprouts was originally designed (as AsProject) to solve a specific set of problems and was later entirely refactored to become a modular set of libraries that are built on top of Ruby, RubyGems and Rake." -- Luke Bayes
- Sencha Touch 1.0 Ships - Now Free!
"So how will Sencha monetize? The company plans to sell its tools, like Sencha Animator, at a premium. It’ll also offer premium support plans." -- Tech Crunch
Helps
"Does anyone have experience with (slower) performance on EC2 compared to Heroku"
Some suggestions:
- Test network lag
- The small instance, the default, is just too wimpy to run as an application server
- Make sure your database instance is big enough, and has enough memory
- Any experience with RDS?
"Can you run cucumber with its own database instance?"
Responses:
- By default, Cuke creates its own environment, but piggy-backs on the test database
... cucumber: <<: *TEST ...
rake db:test:prepareis wired to :test and won't support a :cucumber in the database.yml without extra rake tasks that have continuing maintenance costs- I've used the parallel_tests gem in the past, which has managed to retrofit db:test:prepare to work with multiple test databases, but it did require an extra step after each migration (and it didn't play well with postgres text indexes).
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.
The solution: 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.