Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: [M3-7863] - Use happy-dom instead of jsdom in unit tests #11085

Merged

Conversation

bnussman-akamai
Copy link
Member

@bnussman-akamai bnussman-akamai commented Oct 10, 2024

Description 📝

  • Replaces jsdom with happy-dom 😄
  • I recommend googling jsdom vs happy-dom to understand the basic differences but here are some extra callouts
    • happy-dom should perform better than jsdom 🏎️ (Not seeing a huge boost in perf, but it seems to be ~30sec to 1 min faster in CI)
    • Test stability seems the same (there are no stability regressions with happy-dom) 🪨
    • In my opinion, the main "risk" with happy-dom is its lack of maturity although this doesn't seems to have any significant impact on us. This was, for the most part, a drop-in replacement. 👴
    • happy-dom is known to work on the Bun runtime whereas jsdom does not work (yet). This doesn't matter at all for us right now, but if we ever consider the Bun runtime in the near future, this change might be nice. 🥟
    • For whatever reason, happy-dom seemed to be more correct with the css that it renders. (In the diff, you'll see some changes to toHaveStyle assertions. happy-dom seems to be more inline with what the browser does which is good) 🎨

Changes Required 💻

  • I had to update some style assertions (toHaveStyle)
    • I compared the test output to what I see in the browser and happy-dom appears to match what my browser shows, which is a win for happy-dom
  • I had to update a small number of test assertions to use different selectors. I didn't dig deep into why I had to make the changes I did but all of the changes seemed logical. If you have questions on specific changes, I can comment in more detail
  • Some unit tests that tested actions menus never opened the ActionMenu. I had to add a userEvent.click in a few tests to open the ActionMenu before making assertions. Not sure how they were passing on jsdom
  • Had to increase timeout for a Database related test. Don't love this, but not too bad in the grand scheme of things

How to test 🧪

  • Look at diff and make sure changes actually make sense and are not just changes made to satisfy the test 👀
  • Verify the test-manager Github Action passes ✅
  • Run some tests locally and verify they pass
    • This change does not fix timeouts and failures when running a large number of tests locally. This is still an issue. @jdamore-linode mentioned we may be able to increase the global timeout to improve this at some point

As an Author I have considered 🤔

  • 👀 Doing a self review
  • ❔ Our contribution guidelines
  • 🤏 Splitting feature into small PRs
  • ➕ Adding a changeset
  • 🧪 Providing/Improving test coverage
  • 🔐 Removing all sensitive information from the code and PR description
  • 🚩 Using a feature flag to protect the release
  • 👣 Providing comprehensive reproduction steps
  • 📑 Providing or updating our documentation
  • 🕛 Scheduling a pair reviewing session
  • 📱 Providing mobile support
  • ♿ Providing accessibility support

Comment on lines +92 to +94
await waitFor(() => expect(getByText(database.label)).toBeVisible(), {
timeout: 10_000,
});
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The is the only sketchy change, everything else when pretty smoothly

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you tried awaiting a findByText?

Copy link
Member Author

@bnussman-akamai bnussman-akamai Oct 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did try that but the default timeout wasn't long enough 😖 I might be able to revert to findByText but I think his accomplishes the same thing

@bnussman-akamai bnussman-akamai changed the title poc: Reassess hapy-dom poc: Use happy-dom instead of jsdom in unit tests Oct 10, 2024
@bnussman-akamai bnussman-akamai self-assigned this Oct 10, 2024
@bnussman-akamai bnussman-akamai added Unit tests Improves unit test coverage Dependencies Pull requests that update a dependency file labels Oct 10, 2024
@bnussman-akamai bnussman-akamai marked this pull request as ready for review October 11, 2024 14:29
@bnussman-akamai bnussman-akamai requested a review from a team as a code owner October 11, 2024 14:29
@bnussman-akamai bnussman-akamai requested review from mjac0bs and hkhalil-akamai and removed request for a team October 11, 2024 14:29
@bnussman-akamai bnussman-akamai changed the title poc: Use happy-dom instead of jsdom in unit tests change: [M3-7863] - Use happy-dom instead of jsdom in unit tests Oct 11, 2024
Copy link
Contributor

@hkhalil-akamai hkhalil-akamai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a positive change, particularly for the performance improvement to our CI. Nice work 👍

Comment on lines +92 to +94
await waitFor(() => expect(getByText(database.label)).toBeVisible(), {
timeout: 10_000,
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you tried awaiting a findByText?

@@ -33,7 +33,7 @@ describe('Disks', () => {
const { getByTestId } = render(wrapWithTheme(<Disks {...props} />));
disks.forEach((eachDisk) => {
const checkbox = getByTestId(`checkbox-${eachDisk.id}`).parentNode;
fireEvent.click(checkbox as any);
fireEvent.click(checkbox!);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also rewrite this as a userEvent?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally yes, but I want to keep this PR's scope as narrow as possible so it is representative of what was absolutely necessary to change to get happy-dom working

There are so many places where fireEvent is used when userEvent would be preferable 😣

Copy link

github-actions bot commented Oct 11, 2024

Coverage Report:
Base Coverage: 86.99%
Current Coverage: 86.99%

Copy link
Contributor

@mjac0bs mjac0bs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I see you added the WIP label back, so feel free to re-request a review if you're making any changes/found issues and want 👀 again.)

This was looking good and from my reading up on happy-dom vs js-dom, it seemed like sentiment was: 'if you can easily make the swap and tests pass, why not reap the benefits?'.

Unit tests are passing in CI. The changes to tests made sense - though left a comment on one.

Perf improvement on a local run:

js-dom happy-dom
Screenshot 2024-10-11 at 10 02 08 AM Screenshot 2024-10-11 at 9 57 50 AM

@bnussman-akamai bnussman-akamai changed the title change: [M3-7863] - Use happy-dom instead of jsdom in unit tests test: [M3-7863] - Use happy-dom instead of jsdom in unit tests Oct 11, 2024
@bnussman-akamai bnussman-akamai merged commit efa8580 into linode:develop Oct 11, 2024
23 checks passed
bnussman-akamai pushed a commit to bnussman-akamai/manager that referenced this pull request Oct 21, 2024
bnussman-akamai added a commit that referenced this pull request Oct 21, 2024
…tests (#11085)" (#11128)

This reverts commit efa8580.

Co-authored-by: Banks Nussman <banks@nussman.us>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Dependencies Pull requests that update a dependency file Unit tests Improves unit test coverage
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants