Searching DOM

[00:00:00]
>> Steve Kinney: I wanna talk about some of the other selectors in testing library, cuz they will come up later. And so let's just, in here we'll pull up screen, real quick, findByAltTextt, super useful for finding an image with an alt text. Label test is super good. So, let's say if an input field has a label, as long as you know the text of the label, you don't necessarily have to worry about what the test ID is for that field.

[00:00:32]
It will look for, so if it's street address in a label, it will give you back an input field that is labeled with the label, labeled with the label. Placeholder text is useful if you need it, but if you care about people who use accessibility devices, you can just have a screen-reader-only label, right?

[00:00:57]
That's hidden visually, but then also works as the screen reader. So I would argue if you use findAllByPlaceholder, that's a little bit [INAUDIBLE]. The difference too is we're using get and we're using get1, there's get and getAll, you can guess what the difference is, right? Finds are different than gets, and we'll see them later, cuz they also deal with a little bit of problem we were talking about before.

[00:01:22]
Which is, get and getAll, so get will get the one. It'll actually throw an error if there is more than one thing that matches it, right? Which is sometimes useful as well. GetAll, by label, by placeholder, by role we saw, by test ID, by text, by title, for the various things on there, so on and so forth.

[00:01:47]
Get will immediately get it from the DOM. Great, right? Find is super interesting, because what you don't want is your tests to fail because of the time space continuum, right? And so what find does, is it's an asynchronous version of get, where it will try for a certain amount of time that you set, right?

[00:02:09]
So it will go looking for that button, or that whatever, but it will wait until it's on the page, right? So if it does immediately find it, it'll keep trying for a timeout that you can configure, whatever the reasonable default is is what I use almost all the time.

[00:02:25]
But that way, it's like, okay, cool, maybe it's not on the page yet, but it should be on the page soon, right? So, hold on a second. If you don't find it in a few seconds, I think it's like 300 milliseconds, is the default, I'm doing that for memory, then the test will fail.

[00:02:42]
But it won't fail immediately, because it was about to be on the page, but maybe a network request or something took a little bit longer, it will wait and pull for it for a little bit. And so these are asynchronous, they return promises that will either reject or resolve, and the gets will immediately go looking for.

[00:03:01]
So obviously, when I'm mounting one on the page, I know that it's there, right? But if it was something like, go do this thing, and then a whole bunch of other stuff happens, maybe there's an animation, what have you, find is useful, because it will pull and wait for it, right?

[00:03:18]
That said, if it's not gonna be there, now your test is slowed down, in the act of waiting for it, use what you need to use, so on and so forth.