Batteries Included has just released a new open-source library for testing
Phoenix components. The library, called
Heyya, makes it easy to create
and verify snapshots of your Phoenix components, helping to ensure their
correctness and stability. It’s a combination of Phoenix’s
Snapshy that’s been inspired by
react snapshot testing, including
Snapshot testing is a powerful tool that can help to ensure the correctness and stability of your Phoenix LiveView components. It creates a “snapshot” of the component’s rendered output and saves it in a text file. The snapshot is compared to the latest markup during subsequent tests to ensure it has stayed the same.
Snapshot testing can benefit functional components in Phoenix LiveView because these components are typically e straightforward to test than stateful components. Functional components are pure functions without any internal state or side effects. This functional purity means they always produce the same output for a given set of inputs. With snapshot testing, you can create a snapshot of the rendered output of a functional component and then use that snapshot to verify that the component continues to produce the same output for the same inputs. This ensures that the component is correct and stable and can help to catch any regressions or other issues that might not be immediately apparent when manually testing the component.
For this example, let us assume that we are creating a new app and want a unified header text. So we might make a header module that looks something like this:
We can easily create a test that checks to make sure that
works with the following code:
That code is enough to ensure that passing the slot works and produces the
expected result. For so little work with easy maintenance, snapshot testing can
have a great payoff. Under the hood, the return value from this “Header test”
block is getting rendered to a string. Then Snapshy will compare that string
value to the stored in
test/__snapshots__/**/*.snap. If this is the first test
run, Snapshy will store the output in files that need to be added to your source
Code Changes Always
Let us explore that easy maintenance with an example of how snapshot testing, which might appear brittle and hard to use in a changing code base, still allows for a fast development pace.
Later, for example, we might change the component to look like the following:
Notice that we added a default css class that will make the text look nicer. However, it will also make the previous tests fail with an error. We’ll get an error like this:
Rather than writing new assertions that the rendered code contains “text-3xl font-bold tracking-tight text-gray-900”, we can re-run the failing test with a particular environment variable instead.
That environment variable
SNAPSHY_OVERRIDE=true will reset the snapshot, so
all future tests will assert that the component yields the new expected output.
It’s also straightforward to add a test to show that setting the class attribute
has the desired effect.
mix test, then verify that the new
.snap file contains the expected
‘my-class’ and that’s it. Creating a test that demonstrates the working parts of
the component is as easy as just using the feature. It’s so easy that you’ll
have no excuse.