Common scenario: A team has two types of tests:

1. Unit tests (testing functions and components in isolation, often via @fbjest)

2. In-browser tests (testing the app in the browser, often via @Cypress_io)

The struggle: How do we avoid testing the same things twice?

Two approaches I've seen:

1. Focus mostly on unit testing, and create a small number of in-browser "happy path" tests.

2. Focus mostly on in-browser testing, and only create unit tests when desired.

Trying to cover all scenarios in both leads to a lot of duplicated effort.

That said, I'm not saying redundant coverage is bad. It's often impractical to exercise all code via the browser, especially since in-browser tests are slower.

So comprehensive unit tests are often useful. I'm just searching for a practical balance between the two approaches.

In summary, I don't think mandating 100% unit and browser coverage is the right answer. It's easy to say, but like any practice, there are diminishing returns.

So we have to decide: What balance of unit and in-browser testing gives us sufficient confidence and safety?

View original on X