What _does_ work is front end integration tests with cypress/selenium. You just write some basic tests that click through the flows and see you got to the end. This catches issues all the time where the api response or something has changed unexpectedly and the UI gets stuck half way on an error.
It’s also super simple, it’s 10 likes of looking up elements by ID and running .click(). They hardly ever break from normal UI changes and prove that the app is mostly working as intended.
Switching to TypeScript is also a big one. It’s almost like half a test system given to you for free.
I would also state that "10 likes of looking up elements by ID and running .click()" is a big part of why e2e tests are flaky and hard to maintain. Good e2e tests require good engineering.
We've found that Typescript and a bit of boilerplate has almost entirely eliminated these types of concerns for us.
On the FE, we noticed:
* Most of the bugs were in UX/UI that are very hard to capture in a test suite.
* CSS/UI bugs are better handled with a good UI library. We have an _amazing_ UI dev that's built a really stable UI library for the team.
* It took forever to write FE tests.
* It took even longer to run FE tests.
* Even well-written FE tests miss a lot of subtle issues.
* We rarely had "random" bugs. UI bugs were almost always in the code we changed. Easily detect with quick click testing.