Forum: RSpec (x)HTML Parsing Errors, Cuc 0.2.0 + Rspec 1.2

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Peer A. (Guest)
on 2009-03-24 20:04
(Received via mailing list)
Hello all,

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

Has anyone else run into this?

Peer
Peer A. (Guest)
on 2009-04-07 18:10
(Received via mailing list)
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,

<tr>
  <td>Content</td>
  <td><a href="edit"><img src="icon.png"></a></td>
</tr>

Browser source,

<tr>
  <td>Content</td>
  <td><a href="edit"><img src="icon.png" /></a></td>
</tr>

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.

For reference, we are using:
rspec 1.2.2
Rails 2.3.2
Cucumber 0.2.3
webrat 0.4.3 (patched http://github.com/mmurphy/webrat/tree/master)
Selenium client 1.2.14
Haml 2.0.9

Peer
David C. (Guest)
on 2009-04-07 18:52
(Received via mailing list)
On Tue, Apr 7, 2009 at 8:47 AM, Peer A. <removed_email_address@domain.invalid>
wrote:
> end
> found 3."
>  <td><a href="edit"><img src="icon.png"></a></td>
> 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.
Peer A. (Guest)
on 2009-04-07 18:59
(Received via mailing list)
> 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.

Peer
Peer A. (Guest)
on 2009-04-07 21:46
(Received via mailing list)
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)

http://github.com/pallan/rspec-rails/tree/master

Thanks

Peer A.
Development Team Lead, e-Business

CanadaDrugs.com
24  Terracon Place
Winnipeg, MB, Canada
R2J  4G7

Phone: (204) 654-7951
Fax:  (204) 654-7910
www.canadadrugs.com
David C. (Guest)
on 2009-04-07 22:09
(Received via mailing list)
On Tue, Apr 7, 2009 at 12:08 PM, Peer A. <removed_email_address@domain.invalid>
wrote:
>
> http://github.com/pallan/rspec-rails/tree/master

Hey Peer - would you mind putting in a lighthouse ticket so this stays
on my radar?

http:://rspec.lighthouseapp.com/

Cheers,
David
This topic is locked and can not be replied to.