Feature Request: Detect duplicate test names

[paulmedynski]

Expected Behaviour

It would be nice if Jasmine could be configured to detect and warn/fail when duplicate fully qualified test names are found. This is similar to Issue #747, but asking for a config option to enable the behaviour.

Alternatively, the list of fully qualified test names could be returned to the Reporter in JasmineStartedInfo and the Reporter could choose to detect duplicates itself.

Current Behaviour

Duplicate test aren't detected.

Possible Solution

See expected behaviour.

[slackersoft]

What sorts of issues you're seeing with your suite because of duplicated test names? I'm hesitant to add another configuration option to Jasmine without a compelling reason, so I would like to know more about the "why" for this.

Thanks.

[didaquis]

It’s an interesting idea. So usefull when you have two thousand test writted for others developers.

On this conditions, If some test fail detect which test are throwing error can be confusing if you have multiple test with same description.

[paulmedynski]

@didaquis summed it up nicely. The nested structure of Jasmine tests (describe -> describe -> ... it) make it hard to visualize the full test names when you're in the code. I think the nesting approach is totally fine for writing tests and having common functionality (aka fixtures), but it does obfuscate the full test names. Boost (C++ test framework) has the same nested test definition approach and duplicate name problem, but detects the duplicates for you at runtime.

I'd be perfectly happy if there were a way to query Jasmine for the list of full test names in the jasmineStarted() Reporter callback. Then my reporter could implement the detection. Jasmine knows all of the tests by then (it provides the test count in the callback), so presumably there is a list of tests somewhere that could be queried.

If someone can point me to the place in the Jasmine code where the tests are compiled, I could probably write a patch.

[slackersoft]

Jasmine doesn't really see the duplicate test names as a problem. I can see the usability concerns if all you have to go on is the full name of the spec that failed, but Jasmine also provides the stacktrace for errors as well. Most environments now also include at least filename if not also line number at this point, so I would expect that to help find the spec that is failing.

I don't think we want duplicate test names to cause the suite to fail as a default, but we can discuss how it might be implemented as an option, and how to present the error (or warning?) to the user. Some topics for this:

• When should Jasmine detect the duplication?
  • Suite compilation
  • execution
  • other?
• Does the entire suite fail just because you have two specs with the same full name?
• How do you tell the user about the error?
  • What does the HTML Report say
  • node.js console log
  • how do you tell karma
  • gulp
  • others

[didaquis]

In my opinion throw an error is too much, a warning will be nice. I think it's important don't break test suites written before implement this feature.

[elliot-nelson]

I find this idea interesting as well.

I think a common thread here is detecting potential errors, like:

• Potentially copy/pasted tests (this issue)
• expect() with no matcher (Suggestion: detect expect() without matcher in core #1696)
• a spec with no expects (kind of supported -- but only the HtmlReporter shows it, never displayed for JUnit or console output)

All of these things and more are detected by linters, using plugins like https://github.com/tlvince/eslint-plugin-jasmine. It might make sense to have some kind of decision about where the boundary should be between jasmine and the linter (if jasmine will do error detection, which kinds, and why?).

[slackersoft]

Given the presence and availability of linting plugins as you've noted and the existing complexity of Jasmine already, I'm inclined to keep that type of detection outside of Jasmine itself. I might actually be more inclined to add a link of some kind to the documentation to the appropriate linter options to allow users to catch the types of errors that are important to them.

[paulmedynski]

That sounds good to me. Even better if there's a TSLint plugin for Jasmine already :)

[slackersoft]

I don't know if there is also a plugin for TSLint, but it sounds like Palantir is also deprecating TSLint to focus on ESLint (https://medium.com/palantir/tslint-in-2019-1a144c2317a9).