Storybook Testing

[bmarchena]

Context

We would like to find an appropriate testing solution for the design system. Storybook offers various kinds of testing methods for these purposes. This discussion will serve to document our various explorations of these methods in order to find the best approach for our project.

Test Runner

Storybook's simplest option for testing is their test-runner. This test-runner will run all existing stories as tests and do one of two things depending on whether or not the story uses a play function.

• Without a play function, the runner will simply test to see that the story renders without any errors. At the moment, none of our existing stories use the play function, so this will be the result of simply using the test runner on our system.
• With a play function, the runner will instead check for errors and whether all play function assertions are met.

Note: In order to use the test runner, you'll have to have a version of the design system running in parallel.

This test runner seems like a good starting point for our system. Our components are currently pretty simple and as the complexity of our stories grows we can use the play function to further improve coverage. It also looks like it would be pretty easy to implement into our CI pipeline as well.

I also spent some time looking into adding the play function to a couple of our existing stories. These are interesting in that they can be triggered from the Storybook frontend under the Interactions tab. They'll run as soon as the story finishes rendering, and you can see the result of the test in the aforementioned tab.

There are some great docs here about writing interaction tests using the play function. It uses RTL and Vitest under the hood, so the syntax should be familiar and make actually writing tests that much easier.

One note about writing interaction tests this way is that all method invocations must be await-ed to allow stepping through the debugger. This will definitely be something to be aware of when testing more complex workflows.

Next Steps

We should continue researching and weighing our options, and there are plenty of others that Storybook offers. Accessibility and unit testing in particular could be worth exploring.

A couple of things to consider going forward:

• The design system as it exists currently isn't as robust as it likely will be in the future. Currently most existing components are custom styled Chakra components.
• It might be worthwhile to consider what we might deem to be an acceptable baseline level of coverage - i.e., how much testing should we do on a standalone button component? is it enough for our simpler stories just to be tested against rendering errors?