{ "componentChunkName": "component---src-templates-blog-post-tsx", "path": "/blog/2021-08-04-interactors-design-systems/", "result": {"data":{"blogPost":{"title":"Interactors: the design systems testing ally","slug":"/blog/2021-08-04-interactors-design-systems/","authorNodes":[{"name":"Charles Lowell","slug":"/people/charles-lowell/"},{"name":"Jeffrey Cherewaty","slug":"/people/jeffrey-cherewaty/"}],"markdown":{"html":"

The reusable component libraries shipped with design systems enable developers to use on-brand and battle-tested components. Developers don't have to re-invent the wheel every time they need a common element like an input, modal dialog, or date picker.

\n

Screenshots of date picker components highlighting clickable areas

\n

If you're building an application with some of these components, you'll want to write some tests. With the date picker component pictured above, a user needs at least four clicks to select a date. That means a UI test will also need to step through those four clicks. Testing this interaction with React Testing Library and Cypress could look like:

\n
cy.querySelector('#date .MuiCalendarPicker-root').within(() => {\n  cy.getByLabelText('calendar view is open, switch to year view').click();\n  cy.getByText('1992').click();\n  cy.getByLabelText('Next month').click();\n  cy.getByText('16').click();\n});
\n

To effectively write a test using this date picker, we had to include specifics about its implementation, like IDs and classes. If the underlying component changes its DOM structure, our tests are suddenly brittle.

\n

There's a well-trod design pattern for fixing this problem: page objects. They're object-oriented classes that serve as an interface. As an application matures alongside its accompanying tests, page objects act as a buffer and a more explicit API for the tests to interact with the application.

\n

Introducing Interactors

\n

At Frontside, we've built Interactors (@interactors/html), a library inspired by page objects that helps teams structure, share, and reuse their UI testing practices.

\n

Interactors evolve the idea of a page object. Modern applications are usually arranged into composable components, and the \"page\" is no longer the dominant unit of organization. An Interactor is similarly composable, and can abstract any level of object in the DOM hierarchy.

\n

Design systems maintainers can build interactors alongside components to reduce the mental distance between the user interface and its testing-friendly abstraction. In the same way strong typing can make components easier to build with, interactors make components easier to test.

\n

Interactors...

\n
    \n
  1. ... are composable, so they make tests easier to write, read, and run.
    2. \n
  2. ... act as an abstraction layer on top of the component's implementation, improving design systems' maintainability.
    3. \n
  3. ... have TypeScript support and provide helpful errors, resulting in an improved developer experience.
    4. \n
\n

Let's take a closer look at each of these advantages.

\n

Interactors make tests easier to write

\n

We provide basic built-in Interactors that correspond to HTML elements, like button, link, and checkbox. Using these alone, you could interact with and assert the majority of cases of a web UI. Take the following example of a collapsable navigation menu test:

\n
import { Button, Link, Heading } from `@interactors/html`;\n\nit('goes to international news page with mobile menu', () => {\n  cy.do([\n\t\tButton({'aria-label': 'Show Navigation Menu'}).click(),\n\t\tLink('International', { 'class' : contains('nav-link')).click()\n\t])\n\tcy.expect([\n\t\tHeading('News').exists();\n\t])\n});
\n

You'll often want to avoid repeating yourself and pack together interactions and assertions that correspond to your design system's components.

\n

It's likely that Nav is indeed a component in our design system. Thus, we can create a Nav Interactor that queries the nav and has actions that a user can perform with it.

\n
it('goes to international news page with mobile menu', async () => {\n  cy.do([Nav().goTo('News')]);\n});\n\nit('goes to entertainment news page with mobile menu', async () => {\n  cy.do([Nav().goTo('Entertainment')]);\n});
\n

Note that we can target the Nav directly and perform the action we care about in a single line. If the component changes its internal classes or markup, these tests won't break. Its Interactor received updates to account for those changes.

\n

Retaking the example from the introduction, you could provide a DatePicker Interactor such that everyone using the pick date component have standard methods to test their features using an interface like:

\n
cy.do(DatePicker.setDate({ day: 16, month: 'August', year: 1992 }));
\n

Composable Interactors also respect their lifecycle in the browser. That means that they don't waste time waiting on dead components or looking for new ones when there's no rendering happening.

\n

Interactors improve maintainability in a design system

\n

Interactors rapidly become design system's maintainers' best friend because they provide freedom by abstracting the testing practice away from the component's implementation. Instead of relying on fragile internal component classes, developers and maintainers can use Interactors as an API contract for the UI.

\n

Typically, developers would target elements in the UI in their tests by reaching into the internals of the components they use. It's common to see tests that target chains of selectors like this one:

\n

#notes-modal-notes-list [class*=\"mclRowFormatterContainer--\"]

\n

However, referencing internal selectors couples the test implementation to the HTML structure of the component; a slight change to the markup may cause tests to fail. Thus, tests are fragile and introduce fear in the design system's maintainers because they have no way of knowing what might cause tests to fail. Worst of all, this fragility makes tests unreliable when updating the design system, which is precisely the kind of system-wide change that you write your tests for.

\n

Interactors are the missing contract between the design system's maintainer and its users. The maintainers can control the API that test authors use to interact with the component. The maintainers can freely change the markup of components without worrying about inadvertently breaking tests. And test authors have a more convenient way to write their tests. In the end, the tests are more reliable and provide more confidence to everyone.

\n

Interactors improve developers' experience while testing

\n

Interactors know more about the components under test than mere selectors, which allows them to provide helpful information while you develop or debug tests. Having an explicit API to test your app provides static checking safety, and understanding that API enables Interactors to provide suggestions when things go wrong in a test.

\n

When you write your test assertions and actions using selectors, you're on your own. There are no checks available while you write the test, or while it compiles. You'll only find out about a typo after running the tests, and inspecting closely why your test is failing although it seems that it should pass.

\n

Interactors bring in static checks for your tests, which means your IDE and compiler can provide more support as you develop:

\n

Screenshot of IDE showing in-line suggestions and documentation about Interactors

\n

Not everything can be found by static analysis in a test, but Interactors are ready to provide helpful suggestions for common small mistakes that are usually hard to debug. For example, if you were looking for a login button in your test case, but forgot for a moment that the button actually reads \"Log In\", Interactors will hint that to you:

\n

Screenshot of interactors suggestion similar elements to the one that was not found

\n

Interactors not only check for presence before committing an action in the UI, they also check if the element is visible—through various heuristics—and that it is enabled. For example, if Interactors did find the button and it is visible but not enabled, it will throw an error like this:

\n

Screenshot of interactors failing a test because the target element was visible but not enabled

\n

Try out Interactors!

\n

If you're still not sure about trying out Interactors, take a look at this pull request in FOLIO, an open-source project, adopting Interactors in their component library:

\n

Screenshot of code diff resulting in refactoring a test using React Testing Library to use Interactors

\n

The selectors are difficult to follow and are quite fragile, while the Interactors are easier to read and focus on testing the app as a user would use it.

\n

You can start using Interactors as part of your current test setup, they're compatible out of the box with Cypress and Jest, so it's easy to get started!.

\n","frontmatter":{"date":"August 04, 2021","description":"Components from a design system make building UIs easy. It should be just as easy to test them. Interactors enable more robust tests for component-based UIs, and improve component libraries' maintainability.","tags":["testing","design-systems"],"img":{"childImageSharp":{"fixed":{"src":"/static/bb88c83f430d07176b473a11176c7d15/31987/2021-interactors-design.png"}}}}}}},"pageContext":{"id":"48bf79e6-a3cc-5beb-91bb-a9f005ae6998"}}, "staticQueryHashes": ["1241260443"]}