#354 new
jarrett (at uchicago)

Have selector with block requires block to return true

Reported by jarrett (at uchicago) | February 16th, 2010 @ 03:43 PM

If you call have_selector with a block, and the block does not return true, the outer assertion fails, falsely reporting that the expected element was not found.

Here's a failing spec:

require 'webrat'

describe '#have_selector' do
    include Webrat::Matchers
    before :each do
        @response = %Q(
            <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
                    <form method="post" action="/messages">
                        <input type="submit"/>

    def should_i_assert?

    it 'works if the block does not return true' do
        @response.should have_selector("form[method=post]", :action => '/messages') # This passes
        @response.should have_selector("form[method=post]", :action => '/messages') do |form|
            # Contrived example. There are indeed cases (too complex for this test)
            # where executing the assertions needs to be conditional. This happens,
            # for example, in some custom spec helpers that delegate to have_selector.
            if should_i_assert?
                form.should have_selector("input[type=submit]")

    it 'works if the block returns true' do
        @response.should have_selector("form[method=post]", :action => '/messages') do |form|

    it 'works if the block ends with an assertion' do
        @response.should have_selector("form[method=post]", :action => '/messages') do |form|
            form.should have_selector("input[type=submit]")

I don't know if this is a feature or a bug. But as far as I can tell, it's not documented anywhere. Significantly, the code examples in the RSpec book don't clue you in to this.

Maybe there is a reason for this. But the fact that Webrat reports the outer element wasn't found is, in my opinion, a big problem, because it sends the developer on a wild goose chase. ("Why can't it find that element?") If we must insist on the block returning true, we should at least change the error message so that it's accurate. Instead of saying "The element doesn't exist," we should say "The element exists, but your block didn't return true." Then the developer would know exactly what to do.

No comments found

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Ruby Acceptance Testing for Web applications.

Shared Ticket Bins

People watching this ticket