Recently, when helping to convert a feature suite to use capybara-webkit, we ran into a problem where, about halfway through, the tests would start erroring out with
Errno::EPIPE is a “Broken Pipe” error. A pipe in Unix is a way for data to flow from one process to another, and a broken pipe means that one end of the pipe isn’t connected anymore. In this case, the pipe was broken because the webkit-server process that capybara-webkit uses went away. And since well-behaved processes don’t normally go away unless you ask them to, we assumed it was crashing.
Knowing what scenario we were dealing with, we could find the specific step that was the source of the problem. The step makes a call to
fork. The way that capybara-webkit closes the browser when the tests are over is by using an
at_exit hook, which is called when Ruby is just about to close. Forking a process clones everything about it, including, in the case of Ruby, its
at_exit hooks. So, what happened was that the fork executed what it needed to execute and then exited like normal, but it meant that it took the webkit-server process with it because of the
This was good news, though. The webkit-server process wasn’t crashing! It was behaving exactly like it was expected to, but just a little premature. To get around the
at_exit hooks, we call
exit! in the forked process, which specifically bypasses
at_exit hooks. This lets our fork get on with its work, and it keeps the server running for the rest of the test suite to use.
So, if you’re in the position where you have to fork in a cucumber suite and you’re using capybara-webkit, make sure you
exit! from the fork, and you’ll save yourself some headaches. If you can help fix this problem for good, pull requests are welcome.
I was upgrading Gemcutter to Cucumber and Capybara 1.0 yesterday from Webrat (a change long overdue!), and I discovered a neat little class within Capybara that is worth sharing. Basically, since I was moving the app from Webrat, matchers like
assert_have_selector are no longer available. Capybara’s
Node class has a great
Matchers mixin with tons of goodies that can be used like so, in RSpec:
page.should have_content("This should be on the page") page.should have_selector("a[href='http://thoughtbot.com']")
Great, but how does one use that in functional/controller tests?
Capybara::Node::Simple, which I found purely by chance when source diving. This class’ docs proclaim its usefulness:
It is useful in that it does not require a session, an application or a driver, but can still use Capybara’s finders and matchers on any string that contains HTML
Bingo! Now, how to use in our test suite? We’re still on Test::Unit for Gemcutter, so I had to do the following in
class Test::Unit::TestCase def page Capybara::Node::Simple.new(@response.body) end end
Now the Gemcutter test suite can do assertions like so:
assert page.has_content?("Rails (3.0.9)") assert page.has_selector?("a[href='/gems/rails/versions/3.0.9']")
The whole diff is on GitHub if you’d like to see all of the changes of moving our functional tests from Webrat to Capybara.
Gabe also found out that there’s also a shortcut in Capybara for creating a
Capybara.string. The docs for this show that it’s basically sugar on top of the
node = Capybara.string <<-HTML <ul> <li id="home">Home</li> <li id="projects">Projects</li> </ul> HTML node.find('#projects').text # => 'Projects'
I think this pattern is really useful not just for upgrading suites from Webrat, but really anywhere you have an HTML fragment or string that you’d like to use Capybara’s matchers on.
Akephalos is a well-written driver that integrates soundly with the htmlunit virtual browser. However, as well-integrated as Akephalos is into both Capybara and htmlunit, it can only ever be as strong as htmlunit. As our applications became more sophisticated and large, we began to run into issues with htmlunit.
These issues made us realize that virtual browsers like envjs and htmlunit are never going to keep pace with actual browsers. If we want to write applications using features from the latest and greatest browsers, we’re going to need to test with them, too.
That brought us back to the old mirage: Selenium. Selenium is well-supported, well-maintained, and works with real browsers. Integration with Ruby tests has improved considerably since the old Webrat days, and speed is better in some cases, as real browsers have been heavily optimized.
However, Selenium still has some ongoing issues that aren’t easy to solve:
We were forced to use Selenium because we needed all the capabilities of a real browser, but all these issues kept us looking for something better.
It was possible. I’d like to introduce a headless WebKit driver for capybara: capybara-webkit.
capybara-webkit has the following benefits:
We designed capybara-webkit to solve the problems we had with other solutions, and so far it fits the bill nicely. We believe the quest is far from over, but we invite you to try out capybara-webkit on your own and see if this latest tool can take you a little further on your quest for the perfect testing solution.
Please keep in mind that this is a new driver and isn’t battle-tested as well as Akephalos or Selenium. If you discover any bugs, please report them in Github Issues. We’d also be happy to accept tested patches.
End-to-end testing with RSpec integration tests and Capybara
Unit and Functional Tests are as Useful as 100% Code Coverage
Detect emerging problems in your codebase with. We’ll deliver solutions for fixing them, and demonstrate techniques for building a Ruby on Rails application that will be fun to work on for years to come.