-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
Closed
Milestone
Description
π Feature Proposal
From jest-community/eslint-plugin-jest#1210 (comment)
Let's axe the following matchers:
expect(a).toBeCalled();
expect(a).toBeCalledTimes();
expect(a).toBeCalledWith();
expect(a).lastCalledWith();
expect(a).nthCalledWith();
expect(a).toReturn();
expect(a).toReturnTimes();
expect(a).toReturnWith();
expect(a).lastReturnedWith();
expect(a).nthReturnedWith();
expect(a).toThrowError();
in favor of their native counterparts:
expect(a).toHaveBeenCalled();
expect(a).toHaveBeenCalledTimes();
expect(a).toHaveBeenCalledWith();
expect(a).toHaveBeenLastCalledWith();
expect(a).toHaveBeenNthCalledWith();
expect(a).toHaveReturned();
expect(a).toHaveReturnedTimes();
expect(a).toHaveReturnedWith();
expect(a).toHaveLastReturnedWith();
expect(a).toHaveNthReturnedWith();
expect(a).toThrow();
Motivation
- Removing duplicated matchers will return Jest's size a little
- We've already identified the preferred matcher in each set
no-alias-methods
provides a migration method, which can be automatically fixed- it's easy to extend the matchers Jest has, so folks can re-alias these themselves if they wish
- eventually this would let external tools (like
eslint-plugin-jest
) shave off a little complexity i.e. by not having to check for two matchers
Example
No response
Pitch
Because the matchers are in the jest core.
silverwind and tkrotoff