On the subject of front-end testing — or testing of different varieties of growth, for that matter — my philosophy is to run unit exams as wanted however to primarily deal with integration testing. I exploit Jest or Vitest with the React Testing Library to put in writing my integration exams as a substitute of utilizing Cypress or different related instruments, and the exams work very well.
Integration exams permit you to examine that completely different parts are working collectively as anticipated, they require virtually no mocking, and also you don’t want to fret about testing implementation particulars. Plus, writing integration exams is nearly like making a simulation of an actual person interplay, which suggests it’s also possible to check your person expertise (UX) as properly.
Regardless of all of these advantages, integration testing will not be with out its downsides. In my expertise, the primary difficulty has all the time been a scarcity of pace.
Weighing the choices
In a means, it makes a variety of sense that integration testing speeds could be on the gradual aspect. It is advisable render extra parts when testing how they work collectively, and in case you’re working a whole lot and even 1000’s of exams, it may possibly develop into time-consuming. Plus, in case you like to put in writing your tasks in TypeScript, testing instances might be even higher.
So what’s the answer?
One method could be to make the scope of your exams smaller, however doing so can defeat the aim of working integration exams within the first place. Another choice is to mock sure parts — even when they’re not required for a given check — so that you just don’t have to attend for them to render. There are a number of issues with this methodology, considered one of them being that sustaining the mocks when refactoring or including options could be a nightmare.*
A 3rd path to resolving the problem could be to attempt to optimize your app. After all, if the app is working advantageous in manufacturing, then the slower check instances aren’t because of an issue along with your code. As a closing choice, you can additionally take away the TypeScript to keep away from further compilation, however for me, that’s a no-go.
*Full disclosure: I do mock some heavy exterior parts once in a while, however solely when I’m positive it’s going to give me actual positive aspects.
A easy resolution
Sooner or later I discovered** a means to enhance my testing speeds by 50% with only a few modifications to my exams or manufacturing code. Whereas an enchancment that important sounds too good to be true, I promise that it isn’t, and the answer is even easier than you would possibly suppose.
There’s one factor that each front-end software has however is often not wanted in integration exams.
Are you able to guess what it’s? I’ll provide you with a few minutes.
…
…
Kinds!
Integration exams usually are not often rendered in precise net browsers; as a substitute, they use an in-memory library. The commonest one is JSDOM, however there are some doubtlessly quicker alternate options like Glad-DOM.
Once you use an in-memory library, you may’t see the rendered outcome, so to the person, it doesn’t actually matter ifbackground-colour: pink; is utilized to the ingredient or not. Nonetheless, even in case you can’t see them, the rendering engine nonetheless must course of all your types.
Model processing takes a variety of time, and given you can’t view the rendered outcome, it’s time that isn’t properly spent.
So the answer is straightforward: Flip off fashion calculations and luxuriate in quicker exams.
**By discovered, I imply that the answer was advised by David Ortner, the creator of Glad-DOM library. I’m simply giving the credit score down right here as a result of I didn’t wish to spoil the shock!
The implementation
The one factor higher than a easy resolution is a straightforward implementation. All it’s essential to do to show off types is to vary one line of code in your check setup file:
window.getComputedStyle = () => ({ getPropertyValue: () => undefined }With this one line of code, the computation of types is totally disabled and also you’re free to take pleasure in speedier testing.
The exception
Very similar to the answer itself, the implementation additionally could appear too good to be true. And this time, you caught me — there’s a catch! What in case you truly need a few of your types to be computed? This can be the case in conditions the place you wish to check the visibility of a component or a mode used on it.
Fortunately, there’s a resolution. For these situations, it’s attainable to re-enable fashion computation for a single check. When you solely have a number of of those situations, it must be quick work. Nonetheless, you may create some helpers to make it even simpler.
For instance, right here is considered one of my setup recordsdata:
window.originalGetComputedStyle = window.getComputedStyle
window.lightGetComputedStyle = () => ({ getPropertyValue: () => undefined })
window.getComputedStyle = window.lightGetComputedStyle
beforeAll(() => {
window.getComputedStyle = window.lightGetComputedStyle
})
afterAll(() => {
window.getComputedStyle = window.lightGetComputedStyle
})With some helper features:
export perform withRealStylesComputation() {
window.getComputedStyle = window.originalGetComputedStyle
}
export perform withDummyStylesComputation() {
window.getComputedStyle = window.lightGetComputedStyle
}
export perform resetToDummyStyleComputationForEachTest() {
beforeEach(() => {
withDummyStylesComputation()
})
afterEach(() => {
withDummyStylesComputation()=
})
}At any time when I must compute types in a check, I can name the suitable perform and it computes them for me.
A superb device on your toolbox
Now I’ll say one thing that I in all probability ought to’ve stated originally of the put up. After all, if I had, you won’t have caught round!
I discovered the answer described on this put up a while in the past. Since then, libraries have improved their efficiency round computing types. For instance, JSDOM made some modifications, however there isn’t a steady Jest launch that has utilized them, so it’s essential to do it manually. Glad-DOM has additionally made some enhancements.
Even so, eradicating fashion calculation remains to be an enchancment over making code changes. Some work won’t ever be as quick as no work, so I’m maintaining these methods within the codebase, no matter library updates.
Keep in mind: Simply since you get a brand new hammer doesn’t imply it’s a must to throw the outdated one away.