I have seen TDD done successfully, at a few companies. I think it's one of those things where you really have to learn it by doing it with people who already know it. I can well believe that there are people who read a blog post, started doing it, and got terrible results.

It also requires quite a bit of discipline, or commitment, or conscientiousness. It's worth it, but you have to be on the ball. It helps a lot if everyone on the team is experienced in TDD and positive about it, because you can all support each other.

It requires constant occasional investment, in building test infrastructure, updating older tests, etc. Often not a lot, and you can do it as you go. But sometimes, particularly for integration tests, you have to sit down and bash out some sort of framework to make testing tractable at all.

And it's possible it doesn't work everywhere. In my current job, i write a lot of applied maths code, and i haven't worked out how to test-drive that, because i generally don't know what the result should be before i start (i wouldn't need to write it if i did!). Sometimes i can make relative assertions ("the antimatter consumption at warp six should be eight times the antimatter consumption at warp three"), and sometimes i can calculate rough bounds by hand ("the antimatter consumption at warp one should be within 20% of the inverse relativistic mass"). But mostly, i implement something, then run it on a lot of data, plot the output, and decide if it looks roughly right.

You're right, I didn't 'get it' until I worked at a place that was all TDD and I was surrounded by people who took it seriously. It wasn't about 100% coverage or any forced mechanics. It was simply a group of people who were all on the exact same page working on the same exact methodology. Almost a 'cult' of programmers.

> i haven't worked out how to test-drive that

That's exactly it. I don't always see tests as being necessary for greenfield code. You don't have to test drive it. But, you should write tests. Once you figure it out and have things in a place where you're comfortable, write a test so that when you go back and make a change later... you know that the code will break tests and you can be confident of 'change over time'.

I've seen it done properly with unit tests on algorithmic or decision making code (parsers, calculators, complex, deterministic thinking code).

I've seen it done properly with integration tests on integration code (CRUD, messaging, websites, etc.).

However, people do insist on writing unit tests on integration code and when they do it, it all goes horribly wrong.

I was in the middle of writing a reply to the comment you replied to, when i had to stop because my app was crashing in staging, because i had written a unit test for integration code.

I built an app that ran on 30k+ servers across multiple data centers and it had an auto update mechanism because the app needed to be routinely updated with new features.

I had an integration test that ensured that the app would start up correctly and that the self-update mechanism worked. Without those tests, any failure to start would cause me to have to "talk" to 30k+ servers to get it to install a new version of the app. (ssh into each server and re-install the app).

Automating that communication across that many servers (many of which could be rebooting at any time) and ensuring that they all had a running version of the app, was difficult to say the least. How do you even track that the app is running? (You end up having to have a ping mechanism too!)

Of course, I didn't start off with those tests and had to do things the hard way more than a few times. The thing is that once I added the tests, I never once had to do things the hard way again.

So, you can certainly do things the hard way, or you can just write tests and be done with it and work on features instead.