New handling of .each calls breaks no-identical-title

[DanielSWolf]

Earlier this year, issue #786 described that .each blocks with identical format strings erroneously caused no-identical-title messages. This was fixed in PR #788.

It seems that with the merge of PR #814, this faulty behavior happens again.

[G-Rath]

The tests that were added in #788 are passing, so the issue described in #786 is fixed.

If you're experiencing issues, could you please provide a code snippet?

[erkenberg]

Hey, colleague of @DanielSWolf here.

The following should be a minimal example that shows the no-identical-title error for the second it.each, as both use the same template string (but different values as replacement). Same behaviour if you replace both it.each with describe.each. From our perspective those should be fine titles for .each blocks.

describe('Test', () => {
  it.each(['a', 'b'])('%s', replacement => {
    console.log(replacement);
  });

  it.each(['c', 'd'])('%s', replacement => {
    console.log(replacement);
  });
});

[G-Rath]

ah thank you - that's to be expected as we don't do any checking for replacement placeholders. That's next up on my todo list now that I've gotten the .each handling refactored :)

We've already got a couple of issues open for this, but this might not be a direct duplicate as I think they're more for new rules that check you've got a placeholder in your title rather than modifying duplicate title.

I'll handle adjusting the issue as needed to represent the feature request when I've got a few minutes spare :)

[G-Rath]

So I've been thinking about this for a bit and can't decide on what we should consider an identical title or not:

I feel that if you've got two tests next to each other that have a title like this does %s, that should probably be classed as an identical title because while you could have different values in the each, I'd argue if you can't give them a different title then the test behaviour should be the same and so you should be able to merge the two .eachs.

That could be extended to when you also just have a replacement (i.e '%s') because while the values being tested are probably different, that's not a guarantee, and it's very easy to not make them "identical" (e.g. you can just wrap one or both in a describe, or modify the titles just enough to be different).

Maybe the answer here is to provide a ignoreEachsWithReplacements option 🤔

(while I'm fine with not having a perfect answer, my concern here is that you could argue changing this logic later should be considered a breaking change)

[DanielSWolf]

I feel that if you've got two tests next to each other that have a title like this does %s, that should probably be classed as an identical title

We have a number of cases where the format strings are identical, but the format of the tabular data is not. For technical reasons, some cases may require a different data format while still belonging to the same logical test. So we actually want the titles to look identical (to stress that these cases belong together), but are forced to split them into several groups for technical reasons.

my concern here is that you could argue changing this logic later should be considered a breaking change

From our point of view, the breaking change was introduced with #814. Before, multiple it.each tests were allowed to share the same format string. After it, they weren't. For this reason, we have temporarily pinned our version of eslint-plugin-jest to 24.3.5, in the hopes that this breaking change will be reverted in the near future.

Might it be feasible to allow it.each blocks with identical format strings for now, then maybe later add an option that disallows them?

[G-Rath]

in the hopes that this breaking change will be reverted in the near future

Sorry but that won't be happening - it was always a bug that we weren't handling .each in all cases; while I understand that you can argue this is breaking, eslint provides plenty of ways to control the scope of rules ranging from whole code bases to specific lines to allow us to ship these sort of bug fixes without having to do a new major every time.

For technical reasons, some cases may require a different data format while still belonging to the same logical test.

But that's my point: you should still be able to give those tests unique titles in that case, since there is a difference in the data - be it in the .each itself or by wrapping that test in a describe, i.e

describe('when the data is formatted like this', () => {
  it.each ...
});

describe('when the data is formatted like that', () => {
  it.each ...
});

[G-Rath]

just to be clear (and give myself an out 😅): we won't reverting the implementation, but that doesn't mean we won't add support for changing the rule behaviour as an option nor fine-tuning the checking (which is most likely what needs to happen here) - I'm currently angling towards this being the default because it aligns with how the jest docs describe it, but I'm wanting to understand more about the possible alternatives and why you can/cannot take them :)

[MatthewHerbst]

I'm running into the same issue. My tests are setup like the following:

describe.each(FIELD_USER_ROLES)('when the user role is %s', (userRole) => {
  let ctx;
  
  beforeAll(async () => {
   ctx = await setupFieldUserTestContext();
  });
});

describe.each(OFFICE_USER_ROLES)('when the user role is %s', (userRole) => {
  let ctx;
  
  beforeAll(async () => {
   ctx = await setupOfficeUserTestContext();
  });
});

As you can see, these tests cannot be combined due to the setup needed for each set being different. Sure, for now I can change the title to be something like when the field user/when the office user, but that's just being extra verbose for no reason since the replacement value will already indicate to the reader which type of role the user is.

👍 for ignoreEachsWithReplacements

[github-actions]

🎉 This issue has been resolved in version 24.5.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 25.0.0-next.5 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀