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.)
Senior software engineer (embedded) with over 15 years of professional experience, expert knowledge of Linux, Python and C, and less expert knowledge of C++.
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.
"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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.)
What we should expect from tests?
Carlos Gándara ・ Jan 18 ・ 5 min read
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.
Inside each thread there is sequential code, right? What is the impossibility to implement these sequentials code using TDD?
"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.