-
Notifications
You must be signed in to change notification settings - Fork 364
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
test: [M3-7863] - Use happy-dom
instead of jsdom
in unit tests
#11085
Conversation
await waitFor(() => expect(getByText(database.label)).toBeVisible(), { | ||
timeout: 10_000, | ||
}); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you tried await
ing a findByText
?
There was a problem hiding this comment.
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
hapy-dom
happy-dom
instead of jsdom
in unit tests
happy-dom
instead of jsdom
in unit testshappy-dom
instead of jsdom
in unit tests
There was a problem hiding this 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 👍
await waitFor(() => expect(getByText(database.label)).toBeVisible(), { | ||
timeout: 10_000, | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you tried await
ing 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!); |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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 😣
Coverage Report: ✅ |
There was a problem hiding this 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 |
---|---|
packages/manager/.changeset/pr-11085-tech-stories-1728657019139.md
Outdated
Show resolved
Hide resolved
...ages/manager/src/features/Linodes/LinodesDetail/LinodeNetworking/LinodeIPAddressRow.test.tsx
Show resolved
Hide resolved
happy-dom
instead of jsdom
in unit testshappy-dom
instead of jsdom
in unit tests
…tests (linode#11085)" This reverts commit efa8580.
Description 📝
jsdom
withhappy-dom
😄jsdom
vshappy-dom
to understand the basic differences but here are some extra calloutshappy-dom
should perform better thanjsdom
🏎️ (Not seeing a huge boost in perf, but it seems to be ~30sec to 1 min faster in CI)happy-dom
) 🪨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 whereasjsdom
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. 🥟happy-dom
seemed to be more correct with the css that it renders. (In the diff, you'll see some changes totoHaveStyle
assertions.happy-dom
seems to be more inline with what the browser does which is good) 🎨Changes Required 💻
toHaveStyle
)happy-dom
appears to match what my browser shows, which is a win forhappy-dom
userEvent.click
in a few tests to open the ActionMenu before making assertions. Not sure how they were passing onjsdom
How to test 🧪
test-manager
Github Action passes ✅As an Author I have considered 🤔