And I must admit that I've struggled with TDD myself. And I've generally hit a couple of issues:

1) Bug rates in test code for some reason seem to be higher than that in production code. Not sure why. But the end result is a LOT more test bugs than product bugs. I've sat in meetings where people wanted to block shipping the product because of test bugs. No evidence there were any blocking issues in production code.

2) The opportunity cost of TDD style unit tests are rather high. Given the choice I think I'd rather a more in-depth design and code review.

While I think unit tests are valuable, I take a more sparse notion of them. Based on code review and design, unit test the code that you have worries about. Where you think there's a greater chance of a seemingly innocuous change breaking the code.

I've seen little value, in the projects I've been a part of, with the BDD/TDD approach. It does seem like a lot of busy work and not a lot thought put into where the value is. And there's actually pretty good industry data (and I suspect open source data as well) that its actually not hard to determine what parts of a program are going to be the buggiest in production. I'd really love to see a test approach that is density driven...

But with that said, if you're writing a 20,000 line web app, TDD/BDD is probably fine. You can generally kick out the code and get full test coverage in very short order.

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.

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.