Skip to content

findByRole - document ignored #549

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

Closed
john-james-gh opened this issue May 6, 2020 · 10 comments · Fixed by #550
Closed

findByRole - document ignored #549

john-james-gh opened this issue May 6, 2020 · 10 comments · Fixed by #550
Labels

Comments

@john-james-gh
Copy link

john-james-gh commented May 6, 2020

image

Unable to find role "document" and then logs out a list of available roles and clearly shows there is "document".
What gives?

Thank you

@eps1lon
Copy link
Member

eps1lon commented May 6, 2020

Please follow the issue template. More specifically, include the code that lead to this error and ideally provide a https://codesandbox.io.

@john-james-gh
Copy link
Author

john-james-gh commented May 6, 2020

test('should simulate network failure on mount', async () => {
  useJestFetch.reject();

  render(<MyScreen />);

  await screen.findByRole('document');

  expect(screen.queryByRole('main')).not.toBeInTheDocument();
  expect(fetch).toHaveBeenCalledWith(getUrl);
  expect(fetch).toHaveBeenCalledTimes(1);

  useJestFetch.restore();
});

This fails with the error in the screenshot above. But it's not only this test case. In every test case where I try to findByRole('document'); it fails to find it and then proceeds to log out a list where it says there is "document" role. It's contradicting itself

Any other role such as "article" "button" "main" works fine as expected.

To me, it seems like, "document" is not even findable and yet it is listed under the list of findable roles.

P.S.
When i replace await screen.findByRole('document'); with await wait(); the test case passes.

@eps1lon
Copy link
Member

eps1lon commented May 6, 2020

I suspect we query down from document.body but log roles including document.body. The question is: Do we log down from document.body or do we include document.body in the query?

@eps1lon
Copy link
Member

eps1lon commented May 6, 2020

What I don't understand: How would this even work that MyScreen removes the document in which it should be rendered?

@john-james-gh
Copy link
Author

I doubt it removes it. It wouldn't add up. From what I gather "document" in this case represents <body> element, and in the screenshot we can see that <body /> in fact did render and exists.
I think it's even safe to say "document" role = <body />

What it seems to me is that "document" is not findable just like e.g. findByRole("form") is not findable (unless role attribute is defined on <form />)

Are you positive "document" is in fact a role that could be found by findByRole?
It could be that, "document" only shows up on the list but its not actually a role.

Do we log down from document.body or do we include document.body in the query?

According to that console-logged list, we do include it, but the list could be wrong, as in not representing actual findable roles

@eps1lon
Copy link
Member

eps1lon commented May 6, 2020

doubt it removes it. It wouldn't add up. From what I gather "document" in this case represents element, and in the screenshot we can see that in fact did render and exists.

Then why do you query for it? I don't understand what await screen.findByRole('document'); does for you.

What it seems to me is that "document" is not findable just like e.g. findByRole("form") is not findable (unless role attribute is defined on

)

A <form /> requires a name to have the form role e.g. <form aria-label />.

@eps1lon
Copy link
Member

eps1lon commented May 6, 2020

Doesn't really matter what role we're talking about. The current error message is misleading since we never included the container in the list of available roles. #550 fixes this issue.

@john-james-gh
Copy link
Author

john-james-gh commented May 6, 2020

image

In another test case, I have a pop-up toaster component that I would like to test for rendering.

In the screenshot, it can be seen that the component renders as a direct child of <body />
One way to test it, is to findByRole( "document") and then toHaveTextContent('something')
and this doesn't work as "document" can't be found as a role even though according to the logged out list, it should be.

Of course there are alternatives to test this component, like data-testid, which is what I am doing, becuase "document" thing doesn't work and this is why I posting here

Then why do you query for it? I don't understand what await screen.findByRole('document'); does for you.

According to the console-logged list of available roles, it is a legitimate way to test something so why not use it

@john-james-gh
Copy link
Author

Doesn't really matter what role we're talking about. The current error message is misleading since we never included the container in the list of available roles. #550 fixes this issue.

Ok, that settles it then. Thanks.

@kentcdodds
Copy link
Member

🎉 This issue has been resolved in version 7.4.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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants