This is a duplicate of issue #570 , but I am attaching a failing spec and I'll try to explain why I think this is a real issue.
I've attached a failing spec here: https://gist.github.com/1578175
In that issue, @jnicklas closes the issue telling that browsers won't bother about that.
The problem is that because of Nokogiri (or Capybara interacting with it, i am not sure where is the real problem) inserts that xml declaration, Capybara parsing breaks and some of my specs are failing.
Every spec where we test that we have some content, and this content contains accented characters (áéíóú), or where we test that we have a html tag (for example, ) that with the xml declaration get converted to .</p>
<p>The attached spec works properly in my laptop (capybara 1.1.1, nokogiri 1.5.0, rack 1.2,5, rack-test 0.5.7, ruby 1.9.2p180), but fails in my CI server (same version of every gem, ruby, etc, only difference is that is a 64 bit machine).</p>
<p>I'll try to find the problem.</p>
I disagree. Capybara has ways of asserting that the stuff you want to be on the page, actually is on the page. There's has_selector?, find, all and a number of other useful tools, just read the README. Regexp matching against the output of page.body is not how you're supposed to use Capybara. If you're unsure why, please read this thread: http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags. You should regard the output of page.body as debug information for the current state of the DOM. Nothing more.
My mistake then, sorry for the noise. I was used to spec this way sometimes.
The README says:
If all else fails, you can also use the page.html method to test against the raw HTML:
page.html.should match /<span>.../i
Maybe you could consider that this is only a debugging information, and avoid building specs this way.
Also, thanks a lot for Capybara, it helps so much building robust web apps!!!
Advertise page.html in the Debugging section, not in the Querying sec…
As suggested by @jnicklas and @gaizka in #597.
The README says: ...
The README says: ...
Good point, that's a bit misleading there. I've fixed it in c4247f9.