re: Getting Started with Test Driven Development VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Although I believe strongly in testing, the TDD philosophy has never worked for me. I'm sure it is helpful for many others, so I would never go as ...
 

"Although I believe strongly in testing, the TDD philosophy has never worked for me."

It is not an attack on you or making you less professional or capable. It is just a possibility backed by your own words. So don't get me wrong, okay?!

Maybe TDD never worked for you because you are relating TDD with testing. TDD is not about or for testing. TDD is a tool that you use to analise the macro and micro requirements of the solution you need to deliver. Not only that, TDD will help you to design this solution and on top of that you gain confidence to manipulate your code, adding, removing, refactoring, things around. You ending up with a test suite is just a collateral effect, a good one, but collateral nonetheless.

TDD is not and shouldn't be a replacement to Q.A. and shouldn't be considered part of it too.

Answering the question of your article title:

What we should expect from tests?
A lot of different things. But this has nothing to do with TDD.

 

No, I appreciate the feedback. I can assure you that yes, I do entirely understand what TDD is (have for at least half my career), and while the two are inexorably related (ergo TEST-driven), you're correct that they're not the exact same thing.

(Yet, perhaps most annoyingly, many TDD-advocates I've read/spoken to over the years blur the line between testing and TDD, as if you have to use TDD to do testing.)

TDD is all about planning, designing, and then with tests as one of your main tools to that end, and that approach simply has never worked for me. I've tried it.

It's also form of functionality-based design, which had already come to be considered inferior to model-based design back when the most exciting part of Robert Martin's weekday was still "recess". (Although there are still situations where functionality-based design has its place.)

Again, as I said, that doesn't mean TDD doesn't work, or that it shouldn't be used. If TDD works for you, use it. But it isn't a magic bullet. It does not fit every situation or every project, no matter how perfectly you implement it. (And, in fact, there are no magic bullets.)

P.S. That's not my article. Like I said, I merely detailed my own testing habits in a comment there.

code of conduct - report abuse