Test suites are important tools to help ensure the correctness of your application, but the suites need to be architected, designed, and maintained to ensure the test suite itself doesn’t rot and become a burden. This post covers some high level concepts and architecture decisions that keep test suites maintainable.
Figuring out why your feature tests are failing can be difficult, especially when setting up the first few tests in the codebase.
Some tricks to help you fix tests that sometimes fail.
Recently one of our projects called for using the browser’s Geolocation API. We were excited about this project. However, we had an immediate concern about how to test a feature that interacts with one of the browser’s built in APIs.
When strange failures are plaguing Firefox during Travis CI test runs, get a hold of Travis Support, they’ll help you out!
Custom profile settings for Chrome used with Capybara 1.1 stable seem to be getting ignored. Here’s my quick workaround.
At Collective Idea, we ♥ Cucumber, Capybara and ChromeDriver… and alliteration. But we recently encountered an issue with a very Ajaxy Rails app where we need to test a file download and assert its content.
Swapping out Firefox for Chrome is easier than you think!
Need to define a capybara step for double clicking an element? Here’s what we came up with.
There’s something very satisfying about watching your Cucumber test suite run (and pass), especially when the tests are running in your browser. I can’t help but think, “Man, I’m glad I don’t have to do all of this myself.” That’s especially true when your testing requires multiple sessions. The old me would fire up a couple different browsers and get to work. But that was the old me.