I have some cucumber features that are making me scratch my head. After
updating the Rspec 1.2 my features are now generating thousands of
“ignoring
attempt to close tag with other tag” when I run them. The W3C validator
tells me that the XHTML is valid. The good news is that the tests still
pass, but you the nice output is gone.
I experimented with some different combinations of gems to figure it out
but
it all came down to Rspec 1.2.x. If I remove it then the errors go
away.
This happens under both Rails 2.2.2 and Rails 2.3.2
We are finally starting to narrow this down somewhat. Turns out we are
getting the errors because the XHTML is invalid when it comes back from
webrat/selenium.
The specific problem right now happens when attempting to validate that
there are x number of rows in a table. In a normal rspec view test this
works just fine:
response.body.should have_tag(‘table[class=“data”]’) do
with_tag(‘tr’, :count => 5)
end
But as a step in cucumber it fails. Here is the full step
Then /^there should be (\d+) data rows in the table$/ do |count|
response.body.should have_tag(‘table[class=“data”]’) do
with_tag(‘tr’, :count => count.to_i)
end
end
The error is always similar to “Expected at least 30 elements matching
“tr”,
found 3.”
Doing a ‘save_and_open_page’ in this step and looking at the source code
we
find that all of our self-closing tags (img, link, etc.) are not closed.
If
we pause the browser while running the features and view source all
those
tags are closed.
Save_and_open_page source example,
Content
Browser source,
Content
Next we took the invalid HTML and threw it into a normal rspec view test
using the same matcher as above. It failed the same way as the feature
does. If we fix the invalid html by closing the unclosed tags the test
passes.
After that long winded explanation it appears that we are getting
invalid
HTML back from webrat and selenium and the matchers in rspec are choking
on
it. Is there some way to get rspec to deal with this or should we dig
in
and figure out why Selenium/Webrat is returning the “broken” XHTML? We
have
several people beating their heads against a wall on this one so any
suggestions are welcome. Thanks.
using the same matcher as above. It failed the same way as the feature
does. If we fix the invalid html by closing the unclosed tags the test
passes.
After that long winded explanation it appears that we are getting invalid
HTML back from webrat and selenium and the matchers in rspec are choking on
it.
This is going to sound a lot like buck-passing, but the have_tag
matcher in rspec-rails is a wrapper for Rails’ assert_select, which is
what does the actual parsing. So if the fix is to make it more
tolerant of poorly formatted XHTML, that’s going to have to go to the
rails project.
This is going to sound a lot like buck-passing, but the have_tag
matcher in rspec-rails is a wrapper for Rails’ assert_select, which is
what does the actual parsing. So if the fix is to make it more
tolerant of poorly formatted XHTML, that’s going to have to go to the
rails project.
You given us a new direction to pursue, so don’t feel too bad
Thanks.
We found the issue and it was related to how rspec wraps assert_select.
In
rspec-rails 1.1.12 HTML::Document is initialized differently for
response.body than for strings. In 1.2.2 this was changed so that they
were
initialized in the same way. This caused the string to be validated as
XML
and generated the warnings and matcher errors we were seeing . We
patched
assert_select.rb so that strings are initialized the old way and all the
errors went away.
I forked the project on github and the patch is available there (but not
as
a gem)
