DEV Community

Discussion on: Getting Started with Test Driven Development

Collapse
 
danielfoxp2 profile image
danielfoxp2

"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.

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

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.