Deciding on a testing strategy usually runs into the same trap: the idea that more tests equals a safer app. But if you try to test every tiny detail, you'll just end up exhausted because those tests become incredibly fragile the moment you change a single line of code.
Instead of getting hung up on the classic testing pyramid, Kent C. Dodds' "testing trophy" concept feels more relevant for modern development, especially on the frontend. The point isn't really about the shape of the graph; it's about where you actually spend your energy.
My first line of defense is always static types. This is the cheapest way to catch mistakes before the code even hits the browser. But types have their limits; they can't tell you if your checkout flow is broken or if a button looks active but does nothing when clicked.
Then there are unit tests. These are great for pure logic, like a formatter or a parser that doesn't need the DOM or React. But it feels overkill to mount an entire component just to test a simple rounding function.
The most crucial part, for me, is integration testing. This is where most of my testing "budget" goes. I try to test how components, routers, and the network actually interact. Integration tests catch the fatal stuff, like when someone accidentally deletes an error UI or breaks a query key. If you only rely on unit tests for the error message itself, you'll definitely miss these logic breaks.
Lastly, there's E2E. Because they are expensive and can slow down deployment if they become flaky, I don't suggest using E2E for every corner of the app. It's much better to focus on one or two critical paths, like the actual payment process, rather than having dozens of tests just checking if a navigation menu popped up.
A common mistake I see is wasting too much time testing the "UI chrome." For example, checking if Tailwind CSS classes are correct or doing snapshot testing on the whole page structure. The problem is that as soon as the design changes slightly, all those tests fail. Instead of adding value, they just become a burden when you want to redesign.
Before I add a new test, I run it through three questions: 1. If this assertion wasn't here, what kind of bug would actually reach the user? 2. Which layer is the most efficient place to catch that specific error? 3. Will this test break just because of a variable rename that the user wouldn't even notice?
Not everything needs deep testing. The best strategy is knowing when to stop writing tests so you can keep coding without it feeling like a chore.