Here is one of the most frequent questions when doing front-end development: what are you testing, why are you doing it, and how do you make sure you don't overdo it?

Obviously, both extremes, too much testing or lack thereof, are to be avoided. Not testing is a very bad idea and, on the other hand, "over-testing" could be a problem we have to contend with if we lack experience and/or knowledge.

Having experienced both extremes, "over-testing" became a problem when my team brought in Cypress to test our interfaces without knowing exactly what we needed to test. This type of test is tedious to perform and arduous to develop.

Tests that took too long to run ended up discouraging our team, ended being ignored and creating technical debt. But who wants to run 20 minutes of testing to finally commit?

Faced with this problem, we wondered how we could have good test coverage without necessarily requiring many heavy UI tests. It turns out that we used these tests as acceptance tests and, by overusing this kind of testing, we turned the test pyramid upside down since we had a lot more UI tests than component tests.

But how do you test business logic triggered by an interaction, like the click of a button, without UI testing?

With recent frameworks like VueJs and React, we have used technologies like Jest and Mocha, which we were already using to do unit tests, in order to also do acceptance tests. Thus, tests that load interfaces can be avoided with faster/smaller tests with the help of component tests. We have learned that one type of test does not necessarily correspond to a range or scope. With this logic, an acceptance test can be small.

Subsequently, UI testing was only used for cases where one could not test with Jest and Mocha. Thus, its use has considerably decreased and has allowed us to be much more efficient in our development.

And you, have you ever faced a similar situation?