To me that is a bit scary. Tests don't prove the absence of bugs. They can only prove the presence of them.
I never make big changes, even in the most tested pieces of code that have unit, integration, UI, and manual testing without some trepidation. Because the fact of the matter is that these code paths get the reputation they get because a customer comes back and says this doesn't work and we're like, "oh... that's how you use it?"
"I see it the other way: if code has to be written, it should also be tested. If it's valuable enough to have spend the time to implement, it's worth making sure that it works correctly."
I don't disagree. It should be tested. I think our disagreement is if TDD/BDD style unit testing is the best way to do so.
Absolutely, and having a list of where they were (now) present was a real productivity boon.
It's true, I think we're arguing over something very small. I don't think automated testing is the end-all be-all. But I do think it's much much better than not doing it.
I'm a huge advocate of automated testing. And again, just in my experience, the productivity and perceived code quality I saw coming out of the BDD/TDD side of the house didn't seem to be a step in the right direction.
I think that it is slow going, at first. Testing is a different skill than regular coding, and at first it goes slow. But now, I spend much less time writing tests because I already know how to properly write them.
It's hard to properly evaluate the amount of time tests save you because it's an up-front investment. But I can't count the number of times I've wanted to change something fairly large in my codebase, and did so fearlessly, because then all my tests broke and I was able to quickly fix things where they were broken. In one recent project I decided to completely re-do the authentication system, and it only took me about an hour, because I already had an exact list of every place that needed attention, due to having great test coverage.
> It does seem like a lot of busy work and not a lot thought put into where the value is.
I see it the other way: if code has to be written, it should also be tested. If it's valuable enough to have spend the time to implement, it's worth making sure that it works correctly.