fix(jest/no-identical-title): not reporting when using backticks

[himynameisdave]

Currently jest/no-identical-title only checks against regular strings. As a result, this wouldn't get reported:

describe('an odd case where identical titles are not reported', () => {
    it(`this does not work as expected`, () => {
        //  ...test code here
    });
    it(`this does not work as expected`, () => {
        //  ...test code here
    });
});

This ticket fixes that by testing against TemplateLiteral nodes, but will never report if that node is using string interpolation (ie: has expressions, ${} inside it).

Resolves #232

[macklinu]

This is awesome - thank you for contributing a fix! Left a couple of comments around potential errors and code clarity.

[macklinu]

I think that firstArgument can technically be undefined. I'm not 100% sure we are protecting against that case. For example, the following code:

describe()

produces the following AST

{
  "type": "Program",
  "start": 0,
  "end": 10,
  "range": [
    0,
    10
  ],
  "body": [
    {
      "type": "ExpressionStatement",
      "start": 0,
      "end": 10,
      "range": [
        0,
        10
      ],
      "expression": {
        "type": "CallExpression",
        "start": 0,
        "end": 10,
        "range": [
          0,
          10
        ],
        "callee": {
          "type": "Identifier",
          "start": 0,
          "end": 8,
          "range": [
            0,
            8
          ],
          "name": "describe"
        },
        "arguments": []
      }
    }
  ],
  "sourceType": "module"
}

So node.arguments[0] === undefined.

[SimenB]

Good catch, should be a test case

[himynameisdave]

Yep totally agree, will add 👍

[macklinu]

The double !! was a little unclear reading at first. May I suggest?

const hasExpressions = node => node.expressions && node.expressions.length > 0;

That way, the function is always returning a boolean without the extra type cast.

[himynameisdave]

Thanks for the tip!

[himynameisdave]

I think that my thinking was for if node.expressions was not defined, the entire statement would evaluate to undefined (instead of an actual Boolean). Doesn't matter though because undefined is falsey, so I'll make that change to the test against node.expressions.length 👍

[himynameisdave]

@macklinu || @SimenB : I've resolved the comments, just let me know if you need me to fix anything else up! 👍

[SimenB]

Thanks! Solid work 🙂

[SimenB]

🎉 This PR is included in version 22.3.1 🎉

The release is available on:

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

Your semantic-release bot 📦🚀