Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Negated form of prefer-to-have-been-called-once can be confusing #251

Open
geoffswift opened this issue Feb 14, 2025 · 0 comments
Open

Negated form of prefer-to-have-been-called-once can be confusing #251

geoffswift opened this issue Feb 14, 2025 · 0 comments
Labels
enhancement New feature or request

Comments

@geoffswift
Copy link

With the rule prefer-to-have-been-called-once, this code...

expect(mySpy).not.toHaveBeenCalledTimes(1);

can be (correctly) autofixed as follows...

expect(mySpy).not.toHaveBeenCalledOnce();

However there seems to be a common misconception that not.toHaveBeenCalledOnce() means the method was never called. I can see that arguably it reads that way (in English), and perhaps for that reason we should not be encouraging not.toHaveBeenCalledOnce().

I have found many instances where people write not.toHaveBeenCalledOnce() when their intent was not.toHaveBeenCalled() or equivalently toHaveBeenCalledTimes(0).

Worse case scenario this potentially leads to false positive test passes.

I'd be pleased to see an option at least to allow the autofix for the negated case to be disabled. I have set my repo up to ban not.toHaveBeenCalledOnce() using jest/no-restricted-matchers, since we found every single instance of this to be a mistake.

@G-Rath G-Rath added the enhancement New feature or request label Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants