I think that going back and adding tests for existing code is both difficult and, to be honest, a bit boring/unmotivating. Writing tests is also a skill that ta

I think that going back and adding tests for existing code is both difficult and, to be honest, a bit boring/unmotivating. Writing tests is also a skill that takes time to acquire. I think the best way to go about this is to do it incrementally, that would also solve your second point. 1. Start writing regression tests when fixing bugs 2. Start writing tests for new code 3. Start writing tests for old code whenever you touch it Writing regression tests are a bit simpler since the bug report already contains the test case. The odds for the test being useful is higher since this is, in fact, code that can fail. Writing tests for new code is also easier since you have a greater ability to form the new code to be easy to test. For unit testing you will, probably, naturally favour pure functions/components. It is super important that your tests run automatically on any PR or merge to master. If they are not run automatically people will break them and it will be a hassle to fix. One tip for forcing yourselves to write test for new code is using coverage thresholds. For Jest it works like this [0], but remember to also use the collectCoverageFrom to include files that have no tests. Checking thresholds will make it impossible to merge code that lowers the thresholds. Since you already have buy in this is a great way to keep you and your team honest. And lastly, this was focused on unit tests, but in your situation I would probably begin by writing some high level, black box, end to end test. These give you much more bang for the bucks when it comes to answering the question "Have we screwed up something big or can we release this?". [0]: https://jestjs.io/docs/configuration#coveragethreshold-object https://jestjs.io/docs/configuration#coveragethreshold-objec...