re: Getting Started with Test Driven Development VIEW POST

FULL DISCUSSION
 

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 far as to say "don't do it," but I would like to advise that one not embrace it blindly either.

In my 8+ years of programming, I've found that most of Uncle Bob's advice needs to be taken with a very large grain of salt, especially as he has a habit of conflating his personal opinion and emotional bias with fact, and then touting the result as the One True Way™. Time has proven over and over again that, in programming, "best practice" is a purely mythological beast. No practice or methodology is beneficial to every project; if something is helpful to one project, you can be certain it will be proportionally detrimental to another. TDD is no exception to this.

With that said, I do believe all projects require some form of testing, but there are dozens of equally viable methodologies and approaches to this.

Like I said, I don't want to claim that TDD is somehow "bad" or "wrong," but I want to caution that it is not a magic bullet, and its suitability to any project or team should be carefully and critically evaluated.

By the way, I detailed my own testing habits in a comment on this article (below), which is a great companion to yours, I might add. Some may disagree with my way of doing things, but I have written years worth of stable, maintainable production code, with surprisingly little technical debt. My methods work for me, and the proof is in the pudding. (Your pudding may well be different.)

 

in programming, “best practice” is a purely mythological beast

This.

Even more, later in your great comment you state “there are practices that work for me“ which is IMSO the same biased attempt to invent a silver bullet—now among yourself during the time.

What works for me is I do TDD here and there and I don’t there and here. The task, the existing codebase, the current moon phase, the wind speed and my own mood dictate whether it’s TDDoable or better not.

 

Even more, later in your great comment you state “there are practices that work for me“ which is IMSO the same biased attempt to invent a silver bullet—now among yourself during the time.

Except I don't have any silver bullets there. The exact practice varies from one project to the next. ;-)

 

Depends on the implementation, I write a lot of multi threaded code and functions which spawn threads to run control loops, they are very difficult to TDD, in fact, I would say, impossible! You end up writing tests that are more complex than the code itself and completely tie down the implementation, so they are not good tests. You can exploit encapsulation by exposing "hidden" implementation.

code of conduct - report abuse