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

[code-infra] Add react-testing-library eslint plugin #173

Open
3 tasks
oliviertassinari opened this issue Jul 12, 2024 · 3 comments
Open
3 tasks

[code-infra] Add react-testing-library eslint plugin #173

oliviertassinari opened this issue Jul 12, 2024 · 3 comments
Labels
scope: code-infra Specific to the core-infra product test

Comments

@oliviertassinari
Copy link
Member

oliviertassinari commented Jul 12, 2024

configure eslint-plugin-testing-library and fix issues

See mui/toolpad#3648 as an implementation example.

Could also be helpful in:

-import { render } from '@testing-library/react';
+import { render, screen } from '@testing-library/react';

   test('renders content correctly', async () => {
-    const { getByText } = render(<AppProvider>Hello world</AppProvider>);
+    render(<AppProvider>Hello world</AppProvider>);

-    expect(getByText('Hello world')).toBeTruthy();
+    expect(screen.getByText('Hello world')).toBeTruthy();
   });
 });

For example mui/material-ui#41061 (comment)

@Janpot
Copy link
Member

Janpot commented Oct 10, 2024

Now that we're experimenting with vitest, it looks like using global screen (and global cleanup) prevents our tests from running in parallel. We should actually do the opposite of their recommendation if we want to strictly isolate our tests 😄

@oliviertassinari
Copy link
Member Author

oliviertassinari commented Oct 10, 2024

Are they mounting multiple components on the same jsdom instance in the same JavaScript context? I would expect that Vitest uses multiple node processes, and hence it doesn't matter. Or can we assign the right jsdom instance to the screen API with a mutation?

@Janpot
Copy link
Member

Janpot commented Oct 11, 2024

Are they mounting multiple components on the same jsdom instance in the same JavaScript context? I would expect that Vitest uses multiple node processes, and hence it doesn't matter. Or can we assign the right jsdom instance to the screen API with a mutation?

Vitest uses multiple processes, that works, but seems to be about 3x slower than mocha (will have to investigate further). I tried disabling their isolation but it acts too weird, even when disabling the per-file parallelism. Probably a dead end for now, yes...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope: code-infra Specific to the core-infra product test
Projects
None yet
Development

No branches or pull requests

2 participants