Unit Tests

[konstantinschuette]

Describe the chore

For the beginning we should be fine using Jest and the React Testing Library.

Jest is the test runner and provides various utility, which is essential for testing (components), e.g. spying, mocking etc.

React Testing Library provides utility to test the DOM with the ability to fire user events. The testing concept is very similar to E2E tests, e.g. Cypress, as you try to mimic how the user would use the component/ui. That way the tests are easy to understand and maintain, because the tests don't rely on testing the implementation details.

Quote from the react testing library docs:

You want to write maintainable tests for your React components. As a part of this goal, you want your tests to avoid including implementation details of your components and rather focus on making your tests give you the confidence for which they are intended. As part of this, you want your testbase to be maintainable in the long run so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.

[MaxSchaefer]

Thanks for opening this issue. @JannikWibker any take on this?

[JaninaWibker]

My suggestion is to not use jest as it is really outdated and has a lot of baggage attached. jest was created before many standards were solidified and thus has quite a few oddities and had to solve a few issues itself (w.r.t bundling and so on). I'd opt for vitest for unit tests and either playwright or https://www.cypress.io/ for component and integration tests

[konstantinschuette]

My suggestion is to not use jest as it is really outdated and has a lot of baggage attached. jest was created before many standards were solidified and thus has quite a few oddities and had to solve a few issues itself (w.r.t bundling and so on). I'd opt for vitest for unit tests and either playwright or https://www.cypress.io/ for component and integration tests

I wouldn't add E2E tests to this issue, as it would blow up the scope of a single issue, I think. Also, there's much more to talk about. I'll open another issue for that soon.

Tbh. I have no experience with React testing, so it's probably up to you to choose one.

The main reason for running user-centric (E2E-like) tests is that they are executed very quickly and don't require as many resources as Cypress or Playwright. So the tests with the React Testing Library are usually executed in jsom (basically a virtual browser), which makes running those tests super fast compared to Cypress or Playwright. The issue with Cypress/Playwright is that you can't test every use case, as those tests are just too resource-intensive to test each and every combination. So you would make those detailed tests with the React Testing Library.

A benefit of Storybook is that you can import each story and save yourself the setup for the component. Then the DOM tests could be based on this: https://storybook.js.org/docs/writing-tests/stories-in-unit-tests#combine-stories-into-a-single-test

[JaninaWibker]

https://docs.cypress.io/guides/component-testing/overview is what you want (this isn't E2E testing). Don't start with hacky solutions such as react testing library which differ hugely from the actual runtime (jsdom, ..).

You can even do visual regression tests for components which can come in handy sometimes.

In my experience cypress isn't all too slow once it is running, it just has quite a bit of startup time. Haven't really played around with playwright, unsure how performant it is.

Another consideration is doing accessibility and performance/pwa/seo testing as well with something like lighthouse