[Feature]: Detect unused stubs in test code

[cloudlena]

🚀 Feature Proposal

As described in this article, JUnit and Mockito support detecting unnecessary stubs and tell the user to remove them. It would be great to have that feature in Jest.

Motivation

Removing unused stubs makes the test code cleaner and more maintainable.

Example

No response

Pitch

Removing unused stubs makes the test code cleaner and more maintainable. This leads to users writing cleaner and more delightful tests and prevents certain errors from happening when users expect their stubs to be responsible for a specific behavior when actually they have never been called.

[SimenB]

I like this idea! Happy to take a PR implementing it 🙂

[F3n67u]

I am new to jest source code. May i contribute to this feature?

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

[F3n67u]

hi. bot. could you please keep this issue for me?

[Anutrix]

Still waiting for a way to find unused mocks.

[KhaledElmorsy]

Should we only consider not-called as unused? If we assert that a mock wasn't called, it'd also be used right?

[Anutrix]

To me, mock is unused if it matches these 2 cases:

• It was never called during any tests.
• It was never expected(including not cases) in any tests.

For first case, it can only be tested after the test has run(I prefer this because we can show used mock as warnings at end of test) or if we do some kind of dynamic analysis on the source file. For second case, it's a static analysis of the test file so combining this data at end of test run should be fine.

[KhaledElmorsy]

I agree completely in terms of an ideal solution.

It was never expected(including not cases) in any tests.

This would be ideal. But, if we expand it to include any access of the mock state, without tracking if whatever accessed eventually ended up in an assertion, it gets really easy to implements. Not perfect though with the chance of false negatives i.e. assigning to unused variables. It's a tradeoff of effort/complexity and accuracy.

I haven't decided how I feel about implementing something at the level of static analysis, so would tracking the mock state, with its risks, be good enough?

[eirikove]

+1 Would love this feature as well.

[FreddieDev]

Bumping this, would love to see it