Get Elements Exposed in the Accessibility Tree Using the byRole Query
Following the guiding principles of the testing library, your tests should resemble how your users interact with your code. This mindset also applies to your queries. Each query can be customized from an accessibility perspective.
In this lesson, we will look at one of the queries that are part of the queries accessible to everyone's family and the one you should always start with: the byRole query.
The reason why you should always start with this query is that this query allows you to query for elements that are exposed in the accessibility tree and will help you find accessibility issues early on in your code!
Instructor: [0:04] According to the guiding principles of the testing library, our test should resemble how the users interact with your code. The same principle applies to our queries. This is because each type of query can be customized through an accessibility prioritization.
[0:14] This prioritization starts with the queries accessible to everyone, goes on to semantic queries, and ends with test IDs. In these and the next lessons, we will see how the queries that the testing library gives us and understand in which cases they apply.
[0:27] The ByRole query is the first query you want to resort to when you want to query your UI for stuff. This is because, if your UI is accessible, then there isn't much you won't be able to find using this query.
[0:38] Inside the queries accessible to every one family, the ByRole query allows you to query for elements exposed in the accessibility tree. All you need is an area role. If you want to narrow it down even more, you can use an accessible name.
[0:51] Looking at our component, we are going to leverage this Edge1 to act as the example where we can use this query. Because this is an Edge1, by default, it will have the adding role. Let's find this Edge1 using the ByRole query.
[1:04] In our tests, let's destructure the getByRole query from Render. Now, to use the query, the first argument it expects is the area role. In this case, we know it will be an adding, so let's add it.
[1:18] In this scenario, this query as it is right now will work and return as that Edge1, but picture we have one more adding in our code. This query will break. In this case, let us leverage the accessible name to help narrow down the element we want.
[1:33] To do so, we open braces, write a name, and pass a text match saying this is an Edge1. Regarding the text match we just used, we could have used a string if we had desired. In this scenario, to show you how text match works in queries, we have used a regular expression that will do a substring match and ignore the case.
[1:55] Since we'd like to end every test with an assertion, let us leverage the toBeInTheDocument just on matcher to assert that our adding is indeed being rendered. We run our test, and as you can see, it has passed.