4 ms·

As before, I'll ignore appeal to authorities :-). I'll try to rephrase my doubt about TDD. It seems to be the case that TDD proponents claim that A. Developer

As before, I'll ignore appeal to authorities :-). I'll try to rephrase my doubt about TDD. It seems to be the case that TDD proponents claim that A. Developers not following TDD tend to produce poorly testable code that may be unnecessarily general i.e. attempting to solve problems that need not be solved given the problem. B. TDD solves the problems by setting a prescriptive template (red -> green -> refactor) The "refactor" part of B includes syntactic manipulations (e.g: renaming variables, merging if statements,...) which requires little creativity or insight and generalization which usually do require creativity and insight. My question is this: If you accept A how can you trust the developer to correctly "generalize" in B ? I am really interested in an non trivial example that benefits from "return 9" testing. How about the following problem that does not require one to be a domain expert: implement the function: areCoPrime( a : Int , int b : Int) : Boolean that returns true IFF a and b are co-prime. What examples will you test for and how and at what point would you generalize?

mpweiher 8y ago
> appeal to authorities : There are no appeals to authority here, just references to more information. You know, this "web" thing, with links and stuff. I don't think it'll ever take off... > rephrase my doubt about TDD Hmmm...so you no longer hold on to your previous claim of TDD being about selectively turning the brain off? > TDD proponents claim that > A. Developers not following TDD tend to produce poorly testable code that may be unnecessarily general No. Pretty much all developers have a tendency to do that: http://www.lmgtfy.com/?q=%22Premature+abstraction+is+the+root+of+all+evil%22 > B. TDD solves the problems by setting a prescriptive template (red -> green -> refactor) No. First, no mechanical prescription can solve this problem. Second, if anything the "solution" is to follow YAGNI[1] and DTSTTCPW[2]. As I have explained before and you continue to ignore, where TDD helps is by splitting the task into two, or better, three phases 1. Write a test You are asked to produce a specific test case, not really that much of a chance of overgeneralising (though not zero chance, see parallel thread). 2. Write minimal code to make the test pass Since you are only asked to make the test pass, and the goal is to do this as "stupidly" as possible, chances of overgeneralising are again minimised. 3. After the test passes, refactor to remove duplication At this point, you are only trying to remove duplication, you are no longer trying to solve the original problem, so your scope is much more constrained. Is this some sort of mechanical or mathematical guarantee that you cannot overgeneralise? Hell no! As I have consistently maintained, TDD is not a "brain off" technique, though you seem to insist on introducing that straw man, only to then object to it. However, it helps tremendously, by drastically reducing the opportunities for overgeneralising (one phase out of three), and even there drastically reducing the incentive and scope for overgeneralising, because you are focused on something very concrete. [1] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it [2] http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.htm...

mpweiher 8y ago

> appeal to authorities : There are no appeals to authority here, just references to more information. You know, this "web" thing, with links and stuff. I don't think it'll ever take off... > rephrase my doubt about TDD Hmmm...so you no longer hold on to your previous claim of TDD being about selectively turning the brain off? > TDD proponents claim that > A. Developers not following TDD tend to produce poorly testable code that may be unnecessarily general No. Pretty much all developers have a tendency to do that: http://www.lmgtfy.com/?q=%22Premature+abstraction+is+the+root+of+all+evil%22 > B. TDD solves the problems by setting a prescriptive template (red -> green -> refactor) No. First, no mechanical prescription can solve this problem. Second, if anything the "solution" is to follow YAGNI[1] and DTSTTCPW[2]. As I have explained before and you continue to ignore, where TDD helps is by splitting the task into two, or better, three phases 1. Write a test You are asked to produce a specific test case, not really that much of a chance of overgeneralising (though not zero chance, see parallel thread). 2. Write minimal code to make the test pass Since you are only asked to make the test pass, and the goal is to do this as "stupidly" as possible, chances of overgeneralising are again minimised. 3. After the test passes, refactor to remove duplication At this point, you are only trying to remove duplication, you are no longer trying to solve the original problem, so your scope is much more constrained. Is this some sort of mechanical or mathematical guarantee that you cannot overgeneralise? Hell no! As I have consistently maintained, TDD is not a "brain off" technique, though you seem to insist on introducing that straw man, only to then object to it. However, it helps tremendously, by drastically reducing the opportunities for overgeneralising (one phase out of three), and even there drastically reducing the incentive and scope for overgeneralising, because you are focused on something very concrete. [1] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it [2] http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.htm...