Focus State Assertions

[00:00:00]
>> Marcy Sutton: Okay, so I've got something that's opening that. I got the event to work, first of all, now I need to make an assertion. So, I need to grab the test ID off of here. So, it was dropped down item list. I'm gonna wait until I've actually opened the thing, just to make sure.

[00:00:25]
Maybe this is a case for breaking up your test a little bit since I'm kind of mixing setup and assertions into each other. But YOLO, we're going to keep coming [LAUGH]. So, let's do the drop down list. We'll do dropdown.getByTestId.. I'll pass that string in for the drop down item list, and then I am going to assert.

[00:00:53]
And I actually want to go and get this. So, the first item, the first list item and the first anchor inside of that is what's getting focused. So, let's go look at what this gives me.
>> Marcy Sutton: Let's see, getByTestId, I'm gonna go refer to that API a little bit and just to make sure that is gonna work the way that I want.

[00:01:16]
So let's go back to Queries. TestId.
>> Marcy Sutton: ByTestId. So, close out of this.
>> Marcy Sutton: It should return an element to me, doesn't really say, does it? It just says, here you go, and doesn't really tell you what to expect. Here, returns an HTML element. Okay, so that's what we want.

[00:01:47]
That means that I can run query selector on it and go and find the children. So, I'm gonna say, const firstAnchor. And I'll say, dropdownList.querySelector. And I can just pass it an anchor directly. And then I can say, expectfirstAnchor.toHaveFocus.
>> Marcy Sutton: I love these mergers. It was huge pain to do this before those existed.

[00:02:21]
So if I run the test again, wohoo, that worked. And maybe in the spirit of test-driven development, I could go and verify, maybe I go and hack this or something. So, tab index of negative one would technically still be focusable because we're using a script to send focus.

[00:02:42]
Even though it would be taken out of the normal tab order. So, to really test this and make sure that it's really working, I can just do something really quick and dirty and change this to a div. I like to make sure that it's doing what I really expect cuz sometimes it'll pass and it's not actually working.

[00:03:02]
And that did work. So, if I change that to a div, we get that return state of, yeah, it can't focus that item because it's not focusable. So that's pretty cool. If I go back and put this link back in, run the test again. It's just good to verify.

[00:03:20]
Yeah, so, awesome. It's pretty solid. I can assert that focus management and I feel much more confident about that component. If I took a vacation and came back and was a little rusty about how that worked. Or maybe my co-worker who's new to accessibility was adding features to it or something.

[00:03:41]
The test act as a contract for your component APIs. And that's so powerful, especially if you think of automation with continuous delivery and continuous integration. You could prevent a deployment from going out if there's a bad merge or something breaks this. It is, and we'll talk a little bit about the different kinds of tests, but unit tests are great.

[00:04:04]
Especially if you have these reusable components that you used a bunch of different places. You can test those inputs, test those APIs. We even highlighted that issue with the items, maybe there is a more robust implementation of that component that the test kind of highlighted. If someone goes to use it and they don't pass in the items, should it warn you?

[00:04:25]
I don't know, maybe. Maybe there's some kind of like, we could use TypeScript or something and have it be like, eh, you forgot the items, that could help. I mean, it just kind of uncovers these issues where we otherwise, I don't know, we're kind of just winging it.

[00:04:40]
And we don't really know how our APIs might be used or misused. So I think that's super powerful. I'm pretty happy with that.