Open kurtdoherty opened 2 months ago
@willmcvay @adrian-reapit would be good to get a decision on this before we start writing too many new components 🙏 I can do the work, just looking for input on whether we're happy to make the switch.
@willmcvay @adrian-reapit We're currently having to make concessions on the quality of the unit tests written for new work because our current Jest setup (including the Linaria mocks discussed in #158) undermines the value we can get out of testing with React Testing Library.
Unless either of you have any blocking concerns about my proposal here, I'm going to move forward with the changes next sprint.
Context
TL;DR Jest is hard to configure so that the Linaria CSS extraction on components is performed during test runs. Switching to a Vite + Vitest combination is, by comparison, trivial to achieve. This CSS extraction is important when rendering components via React Testing Library (RTL), because without it, the correct styles are not applied to the component under test, undermining many RTL DOM queries.
More details on this issue can be found in #152.
Considerations
While the setup of Vite and Vitest is trivial, it does have a number of important considerations.
test
,describe
andvi
(the equivalent ofjest
). That said, if we don't like the idea of having to add explicit imports for test functions, we can use Vitest'sglobals
option to enable them as globals as per Jest's behaviour.vi.mock
than it does with Jest'sjest.mock
. This is not a problem, just a matter of education for contributors.Proposal
The following work would be done as a single, large PR:
vi
instead ofjest
and importtest
,describe
, etc from Vitest (unless we would prefer to turn on globals?);test
package scripts to run Vitest instead of Jest;note: If we see problems with Happy DOM (e.g. we need APIs that it doesn't support), we can just use JSDOM instead. Happy DOM is faster than JSDOM for some things at the moment but the Console FE team has needed JSDOM for some of our packages.