I've been writing software professional for 20 years and for much of that time I was very skeptical of testing. Even after I started writing tests it was severa

I've been writing software professional for 20 years and for much of that time I was very skeptical of testing. Even after I started writing tests it was several more years before I saw the value of writing tests first. I've moved to doing this more and more, especially when doing maintenance or bug fixes on the back-end. I still struggle with writing valuable tests on the front-end, apart from unit tests of easily extracted logic functions, or very basic render tests that ensure a component doesn't blow up when mounted with valid data. If you write your test after making the code changes, its easier to have a bug in your test that makes it pass for the wrong reasons. By writing the test first, and progressively, you can be sure that each thing it asserts fails properly if the new code you write doesn't do what is expected. Sometimes I do write the code first, and then I just stash it and run the new tests to be sure the test fails correctly. Writing the test first is simply a quicker way to accomplish this. Like others have said when there is a lot of new code - new architectural concerns etc, its not really worth it to write tests until you've sketched things out well-enough to know you aren't so likely to have major API changes. Still, there is another benefit to writing the tests - or at least defining the specs early on - which is that you are not as likely to forget testing a particular invariant. If you've at least got a test file open and can write a description of what the test will be, that can save you from missing an invariant. Think of tests as insurance that someone working on the code later (including yourself, in the future) doesn't break an invariant because they do not know what they all are. Your tests both state that the invariant is intentional and necessary, and ensure it is not broken.