Get Elements Exposed in the Accessibility Tree Using the byRole Query

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.