Peer Allan
2009-Mar-24 18:02 UTC
[rspec-users] (x)HTML Parsing Errors, Cuc 0.2.0 + Rspec 1.2
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 Allan
2009-Apr-07 13:47 UTC
[rspec-users] (x)HTML Parsing Errors, Cuc 0.2.0 + Rspec 1.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,
<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
> From: Peer Allan <Peer.Allan at canadadrugs.com>
> Reply-To: rspec-users <rspec-users at rubyforge.org>
> Date: Tue, 24 Mar 2009 13:02:31 -0500
> To: <rspec-users at rubyforge.org>
> Subject: [rspec-users] (x)HTML Parsing Errors, Cuc 0.2.0 + Rspec 1.2
>
> 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
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
David Chelimsky
2009-Apr-07 14:25 UTC
[rspec-users] (x)HTML Parsing Errors, Cuc 0.2.0 + Rspec 1.2
On Tue, Apr 7, 2009 at 8:47 AM, Peer Allan <Peer.Allan at canadadrugs.com> wrote:> 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.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.>?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 > > >> From: Peer Allan <Peer.Allan at canadadrugs.com> >> Reply-To: rspec-users <rspec-users at rubyforge.org> >> Date: Tue, 24 Mar 2009 13:02:31 -0500 >> To: <rspec-users at rubyforge.org> >> Subject: [rspec-users] (x)HTML Parsing Errors, Cuc 0.2.0 + Rspec 1.2 >> >> 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 >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
Peer Allan
2009-Apr-07 14:53 UTC
[rspec-users] (x)HTML Parsing Errors, Cuc 0.2.0 + Rspec 1.2
> 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 Allan
2009-Apr-07 17:08 UTC
[rspec-users] (x)HTML Parsing Errors, Cuc 0.2.0 + Rspec 1.2
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 Allan 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> From: Peer Allan <Peer.Allan at canadadrugs.com> > Reply-To: rspec-users <rspec-users at rubyforge.org> > Date: Tue, 07 Apr 2009 09:53:23 -0500 > To: rspec-users <rspec-users at rubyforge.org> > Subject: Re: [rspec-users] (x)HTML Parsing Errors, Cuc 0.2.0 + Rspec 1.2 > >> 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 > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
David Chelimsky
2009-Apr-07 17:48 UTC
[rspec-users] (x)HTML Parsing Errors, Cuc 0.2.0 + Rspec 1.2
On Tue, Apr 7, 2009 at 12:08 PM, Peer Allan <Peer.Allan at canadadrugs.com> wrote:> 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/masterHey Peer - would you mind putting in a lighthouse ticket so this stays on my radar? http:://rspec.lighthouseapp.com/ Cheers, David> > Thanks > > Peer Allan > 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 > > > >> From: Peer Allan <Peer.Allan at canadadrugs.com> >> Reply-To: rspec-users <rspec-users at rubyforge.org> >> Date: Tue, 07 Apr 2009 09:53:23 -0500 >> To: rspec-users <rspec-users at rubyforge.org> >> Subject: Re: [rspec-users] (x)HTML Parsing Errors, Cuc 0.2.0 + Rspec 1.2 >> >>> 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 >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >