Testing in react
Hey everyone, I’ve been pondering whether diving into learning how to test React code is worth it. Does anyone here test their React code, and if so, how crucial do you find it? Appreciate any insights or experiences you can share!
5 Replies
I don’t write any automated tests for front end code. What I do is use typescript to catch potential errors during development, test features manually after deploying in a dev environment and finally have Sentry running to catch bugs in prod
Not recommended maybe, but that’s my approach. The few times I did spend time on writing tests they quickly became obsolete because requirements/features changed. In a fast moving environment these changes happen constantly. Perhaps in a more methodic and slow moving environment it makes more sense to write tests for your features.
Oh! Thanks for your feedback. I pretty much do the same: I use Typescript and Eslint to catch potential errors in development and manually test if everything works as it should in the development environment. What I haven't used is Sentry. I'll check it out. Again thanks for your feedback! 👍
I think the problem with FE testing is that so many people do them wrong so there's a perception that they waste time. But if you go to a company and start proclaiming that tests are bad, you may meet a lot of resistance. So learning how to test is important in that regard. I also, sadly, see a lot of companies leaning on code coverage as a measure of good testing when it actually encourages bad tests, but it's a pretty number to show in reports and measure each quarter.
For instance, I see alot of people unit testing their components and hooks. But these things by their nature have side effects and so E2E tests are much better. But E2E tests are slower. So they fill their unit tests with mocks and implementation details for the sake of something running fast and giving a high code coverage number at the end. The tests only fail when changes are made.. even good changes.. and they never catch actual issues because they're mocked with things that work.
I've seen Theo share similar thoughts but it is difficult to find content on how to write good tests cause there's so much nuance involved. I think it's more important to have something alerting to errors and having a process that allows you to get the fix to prod in minutes, not days. Then write tests afterwards in order to prevent regressions because now you have a clear example of something actually breaking and how it broke.. and also because there's nothing worse than a product manager getting mad that the team is fixing the same gosh darn problem for the 3rd month in a row.
in a codebase of a couple hundred components, we test maybe like 5 of them. vast majority of tests are either
- e2e tests in playwright, most of them make assertions about DOM etc, as well as a few screenshot tests
- unit tests for "library code" (for example custom code for working with dates etc). all of these are basically the format
expect(someFunction(input)).toEqual(expectedOutput)Thank you all for your feedback! Much appreciated 👍