Migrate alert component test from @open-wc/testing to vitest

[brentswisher]

This change: (check at least one)

• Adds a new feature
• Fixes a bug
• Improves maintainability
• Improves documentation
• Is a release activity

Is this a breaking change? (check one)

• Yes
• No

Is the: (complete all)

• Title of this pull request clear, concise, and indicative of the issue number it addresses, if any?
• Test suite(s) passing?
• Code coverage maximal?
• Changeset added?

What does this change address?
This is a followup to #1300 which migrates the first test suite to vitest as part of #1009

How does this change work?
This replaces the basic functionality @open-wc/testing was providing with the vitest equivalents as well as adding some custom helper functions to make the transition a little easier:

Helper functions:

• Because we are using Lit web components, we need to ensure that when vitest browser renders the components, the inner shadow dom has rendered. There is a new fixture helper which handles this by mounting the component in a div (or optionally an element passed as an option) and waiting for updateComplete to fire before returning it.
• Similarly, there is an errorFixture helper which should make testing the correct errors are getting thrown.

Custom matchers:

• Many of the tests are currently written to assert specific html content - either in the light dom or the shadow dom, using shadowDom.to.equal. One issue we run into now is that Lit components use marker comments (<!--?lit$864487786$-->) around their bindings. This made alternatives to these matchers (like inline snapshots) run into issues. To get around this without having to radically rewrite our tests I added two helpers: toEqualDom and toEqualShadowDom. These matchers use the @open-wc/semantic-dom-diff library to create html that is clean of those comments as well as cleaning up any whitespace. This allows us to keep our individual tests mostly unchanged.
• We also lose the .to.be.accessible assertion, which was using axe under the hood to perform basic accessibility tests. Instead, now we will use axe-core directly, with a new toBeAccessible matcher which will perform the same tests as before and format the result in a more readable way:

Additional context
We could get away without the DOM helpers by rewriting the tests to not check the DOM and instead use classes, roles. etc to validate specific things look right. I debated that, but this seemed both faster, and less likely to accidentally invalidate a test. With such a large test suite this method seemed the best way forward, but open to other opinions if you have them!

Once this gets merged in, I want to continue on replacing the rest of the tests. With this as a guide I think its something an LLM can pump through pretty quick, but I am not which would be preferred:

• A PR per component. That's easier to review but there will be a lot of them
• One mega PR that replaces all the rest. It will be harder to review but you'll only have to do it once.

Let me know which you all would prefer to review!

[changeset-bot]

⚠️ No Changeset found

Latest commit: 264dd53

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

size-limit report 📦

Path	Size
packages/pharos/lib/index.js	1.05 MB (-0.01% 🔽)

[daneah]

Looks great to me knowing what I know. The utilities here were easy to understand (though maybe a shame we need to roll some of our own, but none of them are overly complicated from what I can see). Looking forward to how these play out across the code base, and I suppose we'll see if/how much further we need to extend as we go along with other components.

[brentswisher]

though maybe a shame we need to roll some of our own

Yeah, I looked around a bit because I didn't love it either. There are currently officially supported packages for Vue, React, and Svelt. I looked at the unofficial vitest-browser-lit that provides the Lit equivalent. Since it is unofficial and the helpers we actually need were so small, it seemed this route made more sense.