Excellent. You've brought up some points that come up commonly. I have some follow up questions:
* To quote Dijkstra, "Testing shows the presence, not the absence of bugs", so presumably, you write tests to build confidence rather than to ensure "that what you think the code does is what it is actually doing". Is this accurate?
* If so, suppose you given a code-base that contains tests. How do you determine how much confidence to place in said software?
* It's very common for the space of possible inputs to be infinite, so you can't possibly test every case. How do you decide which ones are useful to write tests for?
* What is your response to Rich Hickey's depiction of, what he calls, guard-rail programming ("Simple Made Easy" from around 15:30 onwards)?
* Finally, how do know when you've written a good test suite? It's obviously good if it finds bugs, but how do you know that it is good without running it?
Sorry to bombard you, I'm asking because I'm genuinely interested and I want write more robust software.
> Have you ever made changes to some parts of the code, but then worried you might have broken something? With unit tests, you can be confident that your change didn't break any expected behavior.
I must say, I've done every permutation of changing code with/without tests where my changes have broken/have not broken things. Subjectively, I can't say that there has been noticeable correlation in any direction. Perhaps that's because I'm bad at writing tests, but then, how do I write good ones?