React-testing-library: Problem testing popover element still exists in DOM.

[MarceloBonifazio]

I'm trying to test a component in my project that uses material-ui popover, even kept the same code provided by the documentation, the test should be very simple, and passes 100% coverage of the functions (handlePopoverOpen and handlePopoverClose) provided by lib:

But the test that should detect if the popover content is missing from the component failed, I found that in the system, the behavior works as it should, follows a gif:

In the testing library debug, after mouseLeave the content still exists, as if popover did not behave as expected, follows a gif:

I don't know if this is a bug from the material-ui lib, testing-library lib, or my test error, I created an issue in the repo of material-ui with the same question/bug, put the code in stackBlitz, I think it is easier for anyone willing to judge downloading or checking the code.

[weyert]

I don't know how to run the tests on Stackblitz but I can imagine Material-ui's is using a React.Portal which won't work straight away with testing-library. Probably adding { container: document.body } as option as part of the render-method would help with that. See also: https://testing-library.com/docs/react-testing-library/api#render or https://awesomereact.com/videos/aejwiTIBXWI

[kentcdodds]

1st, whether it's using a portal or not shouldn't make a difference because all queries are bound to document.body anyway.

2nd, my guess is that material-ui is doing something async. Maybe try the find* variant of the queries with await to see if that changes anything?

[weyert]

Ah, did that change recently? Always thought we had to do something extra for portals.

[kentcdodds]

That changed when we removed renderIntoDocument (by making that behavior the default). So it's been quite some time.

And now the recommendation is to use screen for queries anyway (though it works just as well to use the return value from render)

[weyert]

Cool, totally missed that 🙈

[PabloDinella]

2nd, my guess is that material-ui is doing something async. Maybe try the find* variant of the queries with await to see if that changes anything?

That's the exact problem, here is the working test with wait utility:
help.zip

[kentcdodds]

Thanks @PabloDinella! I think we can mark this as resolved!