Sometimes I feel bad when writing tests for a bit of functionality ends up taking “so much time”. Then I think about how long it would have taken to get right without tests.

Not just time as in hours to implement, but calendar time involved. You do it once, submit it. The client says “this doesn’t work”, and you fix it. And usually you do this pattern at least once.

Now, each time through the cycle it takes a calendar day for the client to review the app and note the bugs, and takes you a calendar day to fix same. And probably this cycle will happen more than once, because in the process of fixing the first issue you also broke something else.

This is why I’m such a big fan of behavior driven development: get the behaviors for the (feature) up front, and start writing tests. Tests that should pass, and tests where you have an expected error.

Now implement code to make said tests pass.

The client will possibly still come back at you with something that’s wrong. But the likelihood of this - since both you and the client agree on what you’re going to build - is much less.

Also: when you do implement that inevitable bug fix, your tests are there to make sure you don’t break anything else on the way out.