Open srcrip opened 2 months ago
Yeah, I'm not opposed to the library adding something like that. I think I would name it assert_text
since we're asserting there's some text on the page. I'd be happy to review a PR If you're up for it.
I think assert_html
may be preferable because assert_text
implies plain text, ie, the html tags stripped away
That's an interesting thought. I think we read it from different angles (which is always interesting!)
This is where my head's at 👇
As a user of the library, I would expect assert_html
would help me assert that there's some HTML on the page:
assert_html(session, "<div>Could not find user</div>")
But my guess is that people want to use it as an "assert this text is on the page":
assert_text(session, "Could not find user")
I think that's also evidenced by the implementation you suggested -- where you have text
as the argument being passed in (not html
).
And if instead we wanted people to assert on HTML structure, I'm not sure I would recommend that. I typically recommend the opposite because asserting on HTML structure tends to make the tests brittle. For example, what if I add a class or id to my HTML in the first example? I've broken my test for no reason.
If we want to assert on certain aspects of HTML, we should use assert_has
since it lets you target things with CSS selectors.
Finally, I think assert_text
keeps in line with things like Wallaby's assert_text
. We're not trying to keep in line with that, of course, but I do think assert_text
might be what people expect to exist because of previous tools they've used.
To retain the ability to match on html instead of a selector, you can use a helper function like this:
I think this should probably just be added in as it's own function in the Assertions module.