> I'm a developer, I can make any awful code pass any test I want.
How is that statement exclusive to TDD or something that makes TDD unviable?
TDD isn't about trying to pass some tests no matter how. It's supposed to make you think through the problem and define the interfaces before writing the actual code, when it's still very easy to rearrange and adapt the structure. So that the end result is not awful in the first place.
I think it's just a paradigm difference. For me at least, I think better about tests -after- implementation.
A short example. Let's say I had to write a hash function. If I were forced to write a test for it up front, I'd probably do something naive like ensuring the result of hashing("abc") was 123.
Now I start on my code. Oh, I need to return 123, easy enough. Tests pass, ship it!
If I implemented the function first, I'd then think about pitfalls -in- the code. Let's give it weird input. Let's give it empty things. Let's make sure that for 1000 random strings, the hashes are different. Things like that, because those are things I think about when -implementing- the code, and typically not prior.
I'm not saying that to be snide, that's really how my brain would work. I understand everyone is different, so I'm only speaking for myself.
How is that statement exclusive to TDD or something that makes TDD unviable?
TDD isn't about trying to pass some tests no matter how. It's supposed to make you think through the problem and define the interfaces before writing the actual code, when it's still very easy to rearrange and adapt the structure. So that the end result is not awful in the first place.