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

toBeInTheDocument and toContainElement throws error if element is null #41

Closed
alexandernanberg opened this issue Jul 21, 2018 · 4 comments

Comments

@alexandernanberg
Copy link

  • jest-dom version: 1.10.0
  • node version: 10.5.0
  • npm (or yarn) version: 6.2.0

Relevant code or config:

// downshift/src/__tests__/portal-support.js
const {getByTestId, queryByTestId} = render(
  <MyPortalAutocomplete />,
)
expect(queryByTestId('menu')).not.toBeInTheDocument()
getByTestId('button').click()
expect(getByTestId('menu')).toBeInTheDocument()

What you did:

Tried replacing toBeInDOM with any of the new suggested ways (toBeInTheDocument/ toContainElement )

What happened:

Both throws an error then the element is null

Reproduction:

↑ See relevant code or the Downshift repo https://github.com/paypal/downshift/blob/master/src/__tests__/portal-support.js#L57-L60

Problem description:

As far as I can tell there is no way to replace the current usage of toBeInTheDOM with the other functions. But I might be missing something?

Suggested solution:

I think they should accept falsy (or at least null) values and just return false if that's the case

@jgoz
Copy link
Collaborator

jgoz commented Jul 21, 2018

See #34

The recommended approach for testing the existence of elements retrieved via queryBy* is to use toBeNull or toBeTruthy (or even better, toBeInstanceOf(HTMLElement)).

@alexandernanberg
Copy link
Author

Ah I see, I did read through that thread but don't know how i missed that! 😅 It might be a good idea to add that to the readme as well imo

Thanks!

@gnapse
Copy link
Member

gnapse commented Jul 23, 2018

@alexandernanberg you're right. I just updated the README section about this deprecated matcher to be more clear about why this was done and what the alternatives are. Thanks for the tip.

@gnapse
Copy link
Member

gnapse commented Jul 26, 2018

🎉 This issue has been resolved in version 1.11.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

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