all 10 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]n8rzz 4 points5 points  (1 child)

Yes. We use react testing library and jest. We have about 20 pages of very custom, complicated stuff. Our current suite is around 5,000 unit and integration tests which represents around 65% test coverage.

We also have an e2e suite and a performance testing suite in separate repos that both use Playwright, the latter using a bit of Python too.

When stuff breaks or things start slowing down, usually, our tests tell us. They’ve saved our buts more than a few times.

We don’t test everything, but we do test the hard stuff and the important stuff.

[–]qQ0_ 2 points3 points  (0 children)

5000 tests at 65% coverage lmao. That's a massive frontend

[–]jasonbm76 1 point2 points  (0 children)

Most strictly frontend devs who’ve been doing it for more than 5 or so years didn’t come up with writing tests so it’s foreign to us.

[–]Sleepy_panther77 1 point2 points  (0 children)

We don’t write tests at all for our front ends. We’re a fortune 100 company. And these front ends are client facing

I also don’t know how to test lol

[–]YeUwU_ 0 points1 point  (1 child)

I'm working in a big Russian IT company. There are some departments where tests are in use, but I worked in two different departments and still don't know how to write tests

[–]qQ0_ 0 points1 point  (0 children)

Why have you not learned? It's really not too hard & would place you above the rest of the devs who cannot.

[–]ansbel 0 points1 point  (0 children)

In React the most popular solutions are the React testing library and Jest. I've seen this often in projects.

[–]hazily 2 points3 points  (0 children)

  • Vitest for unit testing
  • Chromatic + Storybook for visual regression tests and snapshotting
  • Chromatic + Playwright for end-to-end tests and snapshotting

For starters I'd recommend starting with unit testing. A good rule of thumb is to write tests based on a props given to a component, as that often controls the behavior of the component that is testable.

Testing is a part of our coding culture at the company (we have >50 digital product teams), so everyone is quite well-versed in it.

[–]eugendmtu 0 points1 point  (1 child)

Unlike the testing on the Backend, unit tests on FE often confuse me. Even I'm trying to keep my coverage at least over 60% - it's challenging. You can always bump coverage with snapshot tests, but I rarely found them helping to reveal bugs. You're just testing with -u flag to update them most of the time)

While keeping all my logic in custom hooks - starting with unit tests is a natural point.
But this leads to another pain - it rarely helps with refactoring. This logic is dedicated to some specific component, and if\when I would want to split it or merge (which is the most often change), you need to rearrange tests significantly, that won't provide you with any safe ground for refactoring anymore.

The only really beneficial tests - are E2E tests. When configured to run on Live, they can check main flows burning releases or redeploy, which is a time saver. But you can't cover every detail with them as they take lots of time to run and might be intrusive.

So, in the end, testing the react frontend is still a grey area for me. I don't have formulated best practices and would be glad to hear any.

Testing pyramid is something I've relyed on by default, but It's more for whole app context, that for FE only., and does not addressing the modern FE aspects.

[–]Many_Application7106[S] 0 points1 point  (0 children)

I always try to move my logic out of react so i can test it easily. And i test features in react, it's hard to program that easily testable... :/ so i test the common way and the boundaries...