In the above output you can see that the majority of attributes have been removed, and styles are now included inline. The type="text" on the first input was removed since it is a default. All attributes and properties are also sorted alphabetically to be more stable.

How is this different than x!?

$3

At the end of the day we are trying to test that our components display correctly, and to catch visual regressions, so why not use an image based visual regression tool? These tools require a real browser, and often can be slow and unreliable. Specifically browsers rely heavily on the operating system to render parts of the page such as fonts which can cause slight differences between screenshots taken from your local machine and your CI. You can get around this last part by having a CI or a local docker image but either way your compromising the speed of your tests and development workflow.

With this module we are not rendering actual pixels. Instead it pulls all visual information from the DOM and aggregates it into an HTML snapshot. You can build and compare these text based snapshots during your tests which is quick and repeatable. This allows you to have increased confidence in your tests without slowing down or complicating your work flow.

$3

The key with snapshots is to avoid allowing the implementation details of your tests to leak in.
Snapshots are easy to update, but if too much is leaking in they can often be hard to review.

In an ideal world a snapshot would automatically include just the critical assertions for what
you are testing so that you can confidently refactor your code without breaking your tests.

This is where visual-html comes in. It is a solution for testing the visual aspect of your components
and works to create a snapshot containing only visually relevant information.

$3

Testing the exact classes applied to an element often provides little value.
A simple way to determine the value of a test is to think about when it would break, and in turn which issues it would catch.

In the example below the tests do not know anything about some-class, what it does, or if it even has a matching css selector.

Imagine that some-class is really just a utility to visually highlight our element, our tests do not capture that at all.
By instead testing the applied styles you know that your CSS is actually hooked up properly, and you can have a better idea of
how the element would be visually displayed to the user.

`javascript
test("it has the right class", () => {
const { container } = render(MyComponent);

expect(container).not.toHaveClass("some-class");
doThing();
expect(container).toHaveClass("some-class");
});
`

vs

`javascript
import snapshotDiff from "snapshot-diff";

test("it is highlighted after the thing", () => {
const { container } = render(MyComponent);
const originalView = visualHTML(container);
doThing();
const updatedView = visualHTML(container);

expect(snapshotDiff(originalView, updatedView)).toMatchInlineSnapshot(
"Snapshot Diff:
- First value
+ Second value

-