[test] Mock getComputedStyle to speed up unit tests

[m4theushw]

Related to #3983

The implementation of Window.getComputedStyle provided by JSDOM parses all stylesheets in the page to find only the rules that affect the given element. This makes it very slow when compared to the version provided by a real browser. After investigation, I noticed that we're calling it in at least two places but none of these calls are necessary, taking into account the kind of tests we do:

mui-x/packages/grid/x-data-grid/src/components/GridAutoSizer.tsx

Lines 91 to 92 in 1ac64ba

	const computedStyle = win.getComputedStyle(parentElement.current);
	const paddingLeft = parseInt(computedStyle.paddingLeft, 10) || 0;

mui-x/packages/grid/x-data-grid/src/lib/createDetectElementResize/index.js

Lines 128 to 130 in 1ac64ba

	var elementStyle = hostWindow.getComputedStyle(element);
	if (elementStyle && elementStyle.position == 'static') {
	element.style.position = 'relative';

The first call is used to get the paddings applied to the grid container, but no test sets padding. The second one is only used to set position=relative if it was position=static, which never happens. We can save some milliseconds by not calling this function. Also, all *ByRole queries relay on it to check if the element is hidden or not, but we only use CSS to hide an element in the filter form.

mui-x/packages/grid/x-data-grid/src/components/panel/filterPanel/GridFilterForm.tsx

Lines 298 to 299 in 1ac64ba

	sx={{
	display: hasLinkOperatorColumn ? 'flex' : 'none',

With that being said, the purpose of this PR is to change to run the unit tests with a mocked getComputedStyle that does nothing. The trade-off of using a mock is that toHaveComputedStyle won't work, so either run it in a real browser or assert manually the styles. Another issue is that the *ByRole may return different number of elements between JSDOM and a real browser if the element is hidden by CSS.

Before: (taken from 09c0d35)

After: (taken from 8956bdd)

[mui-bot]

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	263.4	589.2	334.6	396.84	136.312
Sort 100k rows	ms	424.7	936.2	717.6	715.84	166.819
Select 100k rows	ms	115.6	288.1	125.7	166.24	65.239
Deselect 100k rows	ms	112.2	197.2	167.6	157.6	28.463

Generated by 🚫 dangerJS against 485181a

[cherniavskii]

Since we run unit tests in real browsers, is there any value in running same tests in jsdom?
What if we skip all tests in jsdom except those that are skipped in real browsers?

[cherniavskii]

We can move it to https://github.com/mui/mui-x/blob/master/test/utils/createDOM.js now, and remove these lines https://github.com/mui/mui-x/blob/master/test/utils/createDOM.js#L8-L9

[m4theushw]

Since we run unit tests in real browsers, is there any value in running same tests in jsdom?

@cherniavskii Personally I like them. The unit tests are easier to debug, which can be done inside VSCode. To debug the Karma tests I have to open a browser window and use Chrome DevTools.

[cherniavskii]

The unit tests are easier to debug, which can be done inside VSCode.

We can keep them for development, but ignore in CI

[m4theushw]

We can keep them for development, but ignore in CI

@cherniavskii The purpose of the CI is to ensure that all tests will pass in a controlled environment. If we disable unit tests in the pipeline I guess we'll stop caring about them. This may cause that when developing a feature and we want to debug some piece of code we discover that the entire suit fails with JSDOM. Also, some users don't use a real browser to test, e.g. #2945

[cherniavskii]

@m4theushw Good point

[oliviertassinari]

is there any value in running same tests in jsdom?

For me, the value is about speed of iteration.
yarn t name-of-your-file and your test is up and running in no time. The data grid is the only component we have that heavily rely on layout, so for which jsdom can't test a lot of things.

---

As an important note, window.getComputedStyle is used by testing library for a11y assertions: https://github.com/testing-library/dom-testing-library/blob/0226aea74e873ba96dae414edc533c33b1e51867/src/role-helpers.js#L25. It goes beyond the use in the data grid. The speed up might come from there (if it's the same as testing-library/dom-testing-library#390).