Restore the support for matching html and body
#75
Conversation
This effectively reverts 306b8f4 and adds specs for matching `html` and `body` elements. The issue reported in kucaahbe#62 isn't solvable using DOM assertions. DOM tree has to have a root element (`html`). Using `DocumentFragment` extracts a part of the tree, so it won't contain `html` or `body` elements, but that doesn't mean they weren't a part of the input.
|
looks like this bug was a thing for a while: https://stackoverflow.com/questions/37692178/rspec-html-matchers-finds-html-and-body-tags-in-html-without-them |
|
|
||
| it 'should find the body element' do | ||
| expect(rendered).to have_tag('body') | ||
| end |
There was a problem hiding this comment.
suggest adding examples for .to_not have_tag(...), without them it may be easy to introduce same bug in future again.
|
Just to reiterate – this PR doesn't fix the issue raised in #62 or that StackOverflow question. I argue that neither did 306b8f4 - hence the revert of the breaking change and addition of specs to prevent the breakage in the future. I don't think it's possible to support fragment assertions via Nokogiri. If you use expect('<html class="test"><body>abc</body></html>').to have_tag('html', with: { class: 'test' })
# but:
expect('<p>test</p>').to_not have_tag('body') # fails(Losing the ability to assert classes on these elements broke the specs after the 0.9.3 update e.g. here: discourse/discourse#10664) If you use |
|
@CvX thanks for explanation, the argument regarding matching html/body tags attributes sounds good to me, but quirk about matching these tags presence/absence should be signalled. Looks like we should stick with |
|
this PR was included into 0.9.4 version |
| end | ||
|
|
||
| it 'should find the body element' do | ||
| expect(rendered).to have_tag('body') |
There was a problem hiding this comment.
I don't quite understand, the ArgumentError is telling me to add additional options. and it works, I have added with: {...}
but your spec don't have any ?!?
There was a problem hiding this comment.
it's a good point, that's because this code is not fully relevant (as original author was proposing restoring functionality), it was consumed and changed, recent version contains this part changed a bit
This effectively reverts 306b8f4 and adds specs for matching
htmlandbodyelements.The issue reported in #62 isn't solvable using DOM assertions. DOM tree has to have a root element (
html). UsingDocumentFragmentextracts a part of the tree, so it won't containhtmlorbodyelements, but that doesn't mean they weren't a part of the input.