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

[new rule] prefer .not.toHaveBeenCalled() over toHaveBeenCalledTimes(0) #1198

Open
ge65cer opened this issue Aug 17, 2022 · 3 comments
Open

Comments

@ge65cer
Copy link

ge65cer commented Aug 17, 2022

// instead of
expect(testSpy).toHaveBeenCalledTimes(0)

// prefer
expect(testSpy).not.toHaveBeenCalled()

// unaffected
expect(testSpy).toHaveBeenCalledTimes(1)
expect(testSpy).not.toHaveBeenCalledTimes(5)
@G-Rath
Copy link
Collaborator

G-Rath commented Aug 17, 2022

Could you please provide a description of what you'd like, including examples of correct and incorrect code that this rule would check? thanks!

@G-Rath
Copy link
Collaborator

G-Rath commented Aug 19, 2022

I'm not sure if enough of a clear gain here to make it worth having a whole new rule for this (the failure message is very similar, and it could be more consistent depending on the surrounding code), given you could use no-restricted-syntax to enforce this using CallExpression[callee.property.name='toHaveBeenCalledTimes'][arguments.length=1][arguments.0.value=0] 🤔

@park-jemin
Copy link

Reviving this as I'm seeing a lot of areas of this happening within a codebase - would be nice to have an autofixable rule here instead of flagging restricted syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants