I think that with test driven design it is possible to write code to pass tests rather than code that fulfils the intended purpose. The presence of a safety net may make you a little careless on the high-wire.

Yeah, I see that sometimes. It often comes from people thinking they're finished when all the tests pass, rather than when they can't write a failing test.

I think that with test driven design it is possible to write code to pass tests rather than code that fulfils the intended purpose.

But how does one verify the intended purpose? How does one ensure that the code fulfils that purpose? How does one ensure that later changes to fulfil some other purpose don't interfere with purposes already satisfied?

The idea behind TDD is that the tests become the only real specification that matters because they are the only ones that are written formally at the level of code. Yes, it's possible to mis-write a test. It's also possible to mis-write code. Nothing can prevent one from mis-interpreting a poorly-written (or even a well-written) specification from time to time.

That said, good test technique should focus on "black-box" testing -- abstracting implementation away and reducing tests to inputs and outputs that can be mapped to requirements. Given some interaction or input, the code produces some result or output. It's harder (though not impossible) to get that wrong. Also, the process of writing tests reveals weaknesses or lack of clarity in the requirements that might otherwise be missed.

TDD isn't a game for getting tests to pass; test coverage of 100% doesn't prove correctness. But TDD shifts the burden of proof from the developer to the test-writer, who has responsibility for translating user requirements into a verifiable specification (the test) with fidelity. And isn't poor requirements one of the things we hate? TDD reveals that up front, before the coding is done, instead of after when efforts wind up wasted.