-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ignoring whitespace differences assert_dom_equal
?
#62
Comments
assert_dom_equal
?assert_dom_equal
?
Using the test "link_to can accept a block" do
render <<-ERB
<%= link_to "https://www.example.com" do %>
<%= content_tag :span, "Apples" %>
<% end %>
ERB
assert_dom_equals <<-HTML
<a href="https://www.example.com">
<span>Apples</span>
</a>
HTML
end Another case it comes up is when you have the "no-output" things in the template: test "rendering a list" do
assigns users: [User.new("David"), User.new("Jeremy"), User.new("Rafael")]
render <<-ERB
<div>
<ul class="users">
<% @users.each do |user| %>
<li><%= user.name %></li>
<% end %>
</ul>
</div>
ERB
assert_dom_equals <<-HTML
<div>
<ul class="users">
<li>David</li>
<li>Jeremy</li>
<li>Rafael</li>
</ul>
</div>
HTML
end Because of the extra |
@jeremy @matthewd @rafaelfranca @kaspth thoughts? 😬 I am happy to propose a patch/heuristics, just want to get a 👍 on the general direction before I do it – specifically...
|
|
@chancancode yes please 😍 |
I've opened a PR with an initial stab at this here: /pull/71. |
I think in practice a lot of people who tries to use
assert_dom_equal
will run into whitespace issues.For example, if you have this template:
...and in your test:
The test will fail due to whitespace differences.
In this simple case you can fix it by doing
inner_html.strip
, but consider this template:In this case you will have to do something more involved, perhaps using
strip_heredoc
, etc.While they do produce different DOM structures, because they browser doesn't actually render these differences, and that the spirit of the helper is to test "equivalency" (e.g. it ignore attributes ordering), I highly doubt that the current failure is useful (maybe we can give you a strict mode, for edge cases like
<pre>
content etc).Unfortunately, it is not easy to come up with a simply fix for this. Ideally, we would "just do what the browser does", but that is actually not so simple – for one it depends on inputs that we don't have, e.g. the language of the text and things like CSS rules.
That said, I think it's still worthwhile/possible to come up with a Good Enough™ set of heuristics that work for the 99% cases (and if it doesn't work, you can use the strict mode).
Does that sound reasonable? Is this a behavior that we can just change, or would it require an opt-in, and/or going through a deprecation cycle, etc?
The text was updated successfully, but these errors were encountered: