fix(no-identical-title): always consider .each
titles unique
#910
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@SimenB I think we should try and get this sorted before the next major too, as
it has been similarly disruptive to a small subset of users.
I'd be interested in your opinion on this - my understanding of the rule is that
it's trying to enforce this:
As the title should always be provided to reporters whereas other information
(like what line in code the test is on) isn't guaranteed, and so having titles
that are identical on the same nesting level makes it very hard to tell which is
what test in code.
This is easy to handle with static titles, but
.each
supports injecting valuesinto their static titles, making it harder to decide if a title is unique or not
since we cannot predict the final title(s).
I think this boils down to deciding which of these cases we should consider
unique:
Ideally we should be treating all "no injection"s as identical, but the general
issue is how reliably can we determine if there is an injection or not (which I
think we can, we just need the time to implement it).
I think for now we should say for this rule that any
.each
title is unique(which is what this change does), and then follow-up with implementing logic to
handle injections - either as a new rule (e.g.
require-injection-in-each
) oras an option on this rule (e.g.
ignoreEachWithInjections
), or maybe bothdepending on how it plays out.
Fixes #836