Less is more in Capybara 2.1

April 29, 2013 Brian Butz

One of my favorite changes in Capybara 2.1 is ignoring all hidden elements by default. This could be viewed as a limiting of Capybara’s feature set, since you can no longer (easily) test certain elements on a page. I will argue that it steers you into writing tests that are more realistic, causing this limitation to actually enhance the quality of your acceptance tests.

Let’s use the accordions in Twitter Bootstrap as a simple, contrived example of how ignoring hidden elements leads to better and more realistic tests.

[gist id=5479130]

Let’s say we wanted to check for the content of the second accordion. Before, we could have done it like this:

[gist id=5479161]

This won’t work in Capybara 2.1, since the second section of the accordion will be closed when the page initially loads. In Capybara 2.1, we need to actually click on the header of the accordion as the user would to make the content visible.

[gist id=5479173]

This is a simple example to show how Capybara has changed, but doesn’t really show any of the benefit of this change. For that, let’s try and test something a bit more complex.

Let’s say we had a feature that allowed us to zoom in on a single word in a sentence into focus, for whatever reason. Let’s use the classic: “The quick brown fox jumps over the lazy dog” as an example. In Capybara 2.1, we can easily test this.

[gist id=5479206]

First we test that the whole sentence shows up, focus the word we care about, see that it’s still there, and make sure another word in the sentence isn’t showing up. This pretty much exactly describes how the user is going to experience this feature. In previous versions of Capybara, we would have had to test the lack of content either via a visible: false flag to the selector, or through making assertions on the DOM.

There’s definitely some times when you might want to make assertions on invisible elements, and you still can using the :visible option. But, I think for the most part you can get by with this new set of limitations, especially if you start thinking about how your users are actually interacting with the page, and less about how your code is manipulating things under the hood.

About the Author

Biography

Previous
Python web testing for the Ruby programmer
Python web testing for the Ruby programmer

Ruby has a couple of well-known libraries for unit testing, mocking and stubbing HTTP interactions. My typi...

Next
Breakdown Your Work in RubyMine with Tasks
Breakdown Your Work in RubyMine with Tasks

In RubyMine, you can create tasks to breakdown and structure your work. A task can be a simple local task,...

×

Subscribe to our Newsletter

!
Thank you!
Error - something went wrong!