prefer-in-document: `.toHaveLength(1)` vs `.toBeInTheDocument()`
See original GitHub issueeslint-plugin-jest-dom
version: 3.8.1node
version: 16.1.0npm
version: 7.11.1
Relevant code or config
expect(screen.queryAllByRole('option')).toHaveLength(2);
// some action here
expect(screen.queryAllByRole('option')).toHaveLength(1);
What you did:
I want to ensure there is only one option
.
What happened:
The rule wants this to be
expect(screen.queryByRole('option')).toBeInTheDocument();
Reproduction repository:
Problem description:
It’s not the same thing! I cannot assert that there is only one option
now.
Suggested solution:
prefer-in-document
should allow .toHaveLength(1)
. Or there should be an option at least.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:7
- Comments:11 (4 by maintainers)
Top Results From Across the Web
eslint-plugin-jest-dom/prefer-in-document.md at main - GitHub
toBeInTheDocument() . The rule prefers that matcher over various existance checks such as .toHaveLength(1) , .not.toBeNull() and similar.
Read more >reactjs - Property 'toBeInTheDocument' does not exist on type ...
Was facing a problem with toBeVisible() not being found (TS2339: Property 'toBeVisible' does not exist on type 'JestMatchersShape<Matchers<void, ...
Read more >Appearance and Disappearance - Testing Library
toBeInTheDocument() matcher, which can be used to assert that an element is in the body of the document, or not. This can be...
Read more >Guide to testing in React - my software development blog
getBy vs findBy vs queryBy; The act() function ... setCount] = useState(0) const handleIncrement = () => setCount(oldVal => oldVal + 1); ...
Read more >Common mistakes with React Testing Library - Kent C. Dodds
You're likely missing confidence or will have problematic tests ... toBeDisabled() // error message: // Received element is not disabled: ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Based on the discussion in this thread, I’ve put together this truth table of selector type vs assertion style:
The resolution of the
(*By*)
∩.toHaveLength(1)
suggestion of did you mean to use(*AllBy*)
could resolve as(*By*)
with(*AllBy*)
, leavingexpect((*AllBy*)).toHaveLength(1)
,.toHaveLength(1)
with.toBeInTheDocument()
, leavingexpect((*By*)).toBeInTheDocument()
both of which are stable states.
I like your suggestion @nstepien 👍 I’ll have a crack at implementing that