Check out a free preview of the full Enterprise Web App Accessibility (feat. React) course

The "Testing Approaches" Lesson is part of the full, Enterprise Web App Accessibility (feat. React) course featured in this preview video. Here's what you'd learn in this lesson:

Marcy discusses different approaches to testing and various testing tools that can be used. They emphasize the importance of finding the right tools for the job and using whatever helps make testing easier and more efficient. The instructor also mentions specific tools like eslint, axe-linter, Jest, testing library, Cypress, Storybook, and Playwright, and provides insights on how to configure these tools for accessibility testing. They also mention the integration testing and end-to-end testing, and highlight the benefits of using snapshot tests for accessibility and visual testing.


Transcript from the "Testing Approaches" Lesson

>> So some approaches for testing. Now, there's multiple types of tests that could apply to any one component or group of components. And of course, people have different approaches. Your approach might be dictated by what tooling is available to you. So kind of use what you can and find how it fits in, that's totally fine.

And sometimes these lines are blurry. In my opinion, just you should use whatever tooling helps you get the job done, and it's not as important whether it's integration testing or end to end testing. Well, we're using Jest, but they're kinda more integration tests, like we're using Storybook for whole pages, it's whatever gets the job done.

Whatever makes our jobs easier, makes our data so it's not destructive and we can have repeatable test cases, and just make the job easier. So there's linting, with ESLint, ESLint-Plugin-JSX -A11y for React projects. And that one's pretty standard. There's also an Axe Linter, which uses the same engine as Axe core and the Axe extensions.

Those are nice because you can check issues early in development. I think where they're challenging is they sometimes have some false positives that you're like, well, that's not really an issue. The linter couldn't really tell whether that was an issue or not, so you might need to configure your linter so that it doesn't just turn into noise that people ignore.

For unit tests, those can be helpful for internal component APIs and logic. You wanna kind of isolate these components from the outside world so they're not gonna call out to the network, maybe not test other components in conjunction, but hey, do what you need to do. So Jest is a modern tool.

Jest DOM is pretty essential. And then Testing Library, those are kind of the trifecta these days for accessibility unit testing. They are amazing. I've tried a lot of accessibility tools over the years, and I've been paying very close attention to how the browser works and what the tool is doing.

We are in the best time for testing tools we've ever been with what we have right now. It's awesome. For example, if you use Jest in Testing Library to try and send focus to a div, like you're gonna write an accessibility test to do TDD and capture that failure, it will fail because that element is not focusable.

That's what we want. Because we can do true test-driven development style and get a test that fails, just like the issue, we capture it, reproduce it, fix the test. We can do it for accessibility a lot easier than we used to. So check those out. Component testing is another way to go about it.

There's Cypress Component Testing. If you already use Cypress and you like their API, that's totally worth checking out. You can use it for single components or groups of components, whereas regular end-to-end Cypress is more for whole groups of pages. And then don't sleep on Storybook. I'm kind of obsessed with it because it is so awesome.

I joined a new team, they had it set up, but they kinda weren't using it, but we also have data that we have to get from a client, people client, and it's stuff that is destructive action. To test that flow, I have to hit the big button, and then that data's gone, and we have to get a new data.

That's pretty tough. So Storybook allows us to mock that data, have our components not be behind a VPN either, that's kinda nice, cuz I didn't have access for a week or two, but I actually was able to ship fixes using Storybook only. It's awesome. And so now my whole team is like, we love Storybook.

It's like music to my ears. [LAUGH] So it can be very helpful. Even if you're not building a capital D, capital S design system, just find ways to make these tools work for you so that it's easier to test. Sometimes these things are faster too, you get hot reload, you get all the latest and greatest things without some of the constraints of your full environment, it's awesome.

So then there's integration testing. Cypress or WebdriverIO, I mean, you can kind of bend those tools to your will for all kinds of purposes. Integration testing and end-to-end testing are where they are intended to be used. And I think integration testing is when you integrate multiple components together.

For focus management cases, like say I have two components that kind of, you send focus from one to another, that would be a bit outside of the scope of a unit test cuz they're not isolated anymore. But with integration testing, maybe with Cypress component testing too, I could do this.

But I could test to make sure that focus is caught in the right place, it moves around the app in the right way. And then there's end-to-end testing, which I've heard is kind of synonymous with integration testing. There isn't always a clear distinction. The tools for integration testing are usually the same for end-to-end.

Lots of organizations call it something slightly different. It's basically for whole pages. And it's nice to have these tools, say, you have kind of a niche JavaScript framework, maybe you rolled your own or something. You can use Cypress, and maybe WebdriverIO, kind of with agnostic frameworks. So it's a really great tool to sort bolt on to any frontend tech stack, because you don't need ESLint plugins for every single thing.

They might exist, probably not when you've rolled your own CMS and JavaScript framework, but it can be pretty handy. And then I have some things about configuring tools, like questions to ask. How is the UI rendered? We talked about hybrid apps, you've got some web views. Maybe those could be covered in Storybook, but maybe you need other tooling for the mobile wrapper.

Can you inject tooling for accessibility tests into that context? So Cypress args we're gonna look at, that tool will handle injecting args into the web context for us, and that's pretty cool. How is your code bundled? Does it use webpack or Parcel or something else? Cuz sometimes those configs are where you have to look to configure your tooling.

You might have a team that does that. Smaller companies, you might not. Can you make changes to the infrastructure for accessibility tooling, or will you have to make do with what's already there, like my story with user event? I think right now, the project I'm on is locked into a much older version, and I'm gonna have to wait.

[LAUGH] Someday, I'm gonna upgrade that. And just sort of funny, who do I have to talk to to get a configuration change around here? Anyone? [LAUGH] All right, I'm a nerd.
>> Any experience specifically with Playwright or any things to look out for with that?
>> Actually, yeah, I should put that on there.

So Playwright, there's another one, too, for snapshot tests. And I think they can be super handy for accessibility snapshots. Visual snapshots can be useful. I've seen teams disable those cuz they end up being real blocking to progress. So yeah, I think there's some really powerful APIs there, like being able to test things.

I think you can use Playwright more effectively to test Chrome extensions too. So there's some really powerful APIs that you just don't get with other tools. So definitely worth checking out.
>> I always thought that testing library was built with Jest. Are those two just two separate testing options?

>> They are technically separate. I think they really do work well together, but testing library has all of these different flavors now. If I go to testing library, I think under here, so Core API, they have all the school stuff like ByRole, ByLabelText, ByAltText. I mean, Kent C.Dodds, when he writes about testing library, his gotchas and things to watch out for are use by role instead of by test ID.

They're really making accessibility testing central to their recommendations, which love to see it. When we go down here to, where are the, yeah, frameworks. So we have DOM, React, Reason, Native, Vue, all of these flavors that don't necessarily require Jest, I think. So-
>> Also, there's a slightly more recent test runner called VTest that's, it's very similar to Jest, but you can kinda take Jest out, plug testing library in and it basically works.

>> Okay-
>> Love that, so much easier than it used to be. So, yeah, probably another tool that we could add, too. So under ecosystem, there's all these other extensions and things as well. And there's been so many framework libraries over the years, like Selenium WebDriver, and Jasmine, and Mocha, and Sinon, and Enzyme.

Just, we've evolved, right? I think we're in a golden era of testing, also.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now