When we’re talking about unit testing, it is something that developers want to avoid. But what about accessibility?? the same thing, even most developers will say, ‘Nah, I'm good :D’

So, what is unit testing?? Isn’t it enough when we test the feature we developed just works fine? The short answer may not be! I’ll tell you why...

Unit testing is a way of testing a unit — the smallest piece of code that can be logically isolated in a system. In most programming languages, that is a function, a subroutine, a method, or a property. The isolated part of the definition is important. In his book “Working Effectively with Legacy Code”, author Michael Feathers states that such tests are not unit tests when they rely on external systems: “If it talks to the database, it talks across the network, it touches the file system, it requires system configuration, or it can’t be run at the same time as any other test.”

Modern versions of unit testing can be found in frameworks like JUnit, or testing tools like TestComplete. Look a little further and you will find SUnit, the mother of all unit testing frameworks created by Kent Beck, and a reference in chapter 5 of The Art of Software Testing. Before that, it was mostly a mystery. I asked Jerry Weinberg about his experiences with unit testing — “We did unit testing in 1956. As far as I knew, it was always done, as long as there were computers”.

Regardless of when and where unit testing began, one thing is for sure. Unit testing is here to stay. Let’s look at some more practical aspects of unit testing. In fact, the traditional test of our application by black box testing, the thing that we talked about earlier manual testing only finds whether the feature that we developed already works or not.

Then, when we talk about something important thing that most developers skip or miss is about accessibility (a11y).

Accessibility is when we design, and develop products and any application that we put on it our thoughts about how this thing will work for everyone literally everyone, diversity disabilities included.

So when we combine both a11y and unit testing it will lead to perfection.

Here is how I achieved that when developing applications using react.js.

Setup

We need a setup to make our workspace easier. That’s why we need to install some helpful plugins. Here are my top-tier plugins for a11y support in vscode.

• axe Accessibility Linter
• eslint-plugin-jsx-a11y (for React development)

That’s it!

Showcase

When all the tools that you set are already complete, you can run tests.

For example, when an image has no alt text.

Or if you’d like to apply stricter, you can just extend the rule of the eslint a11y to your own eslint.config like this:

{
  "extends": ["react-app", "plugin:jsx-a11y/strict"]
}

Stricter rule applied to the codebase.

Now when you write the test, don’t use id or class. Have role instead, like this:

getByRole('heading', {level: 1})
// <h1>Heading Level One</h1>

getAllByRole('heading', {level: 2})
// [
//   <h2>First Heading Level Two</h2>,
//   <div role="heading" aria-level="2">Second Heading Level Two</div>
// ]

Now it will trigger by role, so part of the a11y won’t missed/skipped right now.

That’s it for today's sharing, thank you and stay tuned for the next article. :)