3 ms·

Thanks for the time you took to reply. Just to get something quickly out of the way, yes - it is a silly example but this is the one you chose or at least chose

Thanks for the time you took to reply. Just to get something quickly out of the way, yes - it is a silly example but this is the one you chose or at least chose to defend. I will be interested to see an an equivalent of "return 9" in an example that is not silly. While you make good points about the value of refactoring and having a well tested code, they are not specific to TDD. Nor do they address my question. It seems to be a fundamental property of TDD that a developer is invited to reduce her mental capacity - up to a point, "return 9" or as you suggested "if ((a == 10) && (b == 2)) return 12". Then something unexplained happens e.g.: "refactor the add method to handle all those cases with less code, by removing the case-handling and doing arithmetic.". What exactly happened here? Why is the developer can now use that big brain of hers 100%, realize that special case handling is not the way to go, and write "a + b"?

mpweiher 8y ago
There is no switch between "brain on" and "brain off", what you describe as "a fundamental property of TDD" to "reduce mental capacity" is just a misunderstanding on your part. > Then something unexplained happens I am not sure why you think this is "unexplained", as it is spelled out in detail in every TDD introductory text. What there is is a switch between (a) trying to get the tests to pass (tests are red) and (b) trying to refactor the code (tests are green). In both cases, you use your full brain, in case (a) you use it to find the minimal code to pass the tests. If you think finding minimal code is a "brain off" activity, well that's a whole different discussion, but I refer you to Saint-Exupéry[1] and Blaise Pascal[2], for starters. And in each case you use code as forcing functions for other code. The tests force you to write the production code. Writing only the least possible production code that passes the tests forces the tests to actually test what you want them to test. If you write code that does significantly more than what your test requires, you won't have test coverage for that excess capability. And so if the rest of your program exercises that excess functionality and you break it, your program will break without your tests giving you a warning. Also, the silliness of the example is of course what makes it a good illustrative example. If we had to first become domain experts with s shared understanding of some random domain, it would make talking about TDD itself much harder. It does require the ability and willingness to use it as an illustrative example. [1] https://www.goodreads.com/quotes/19905-perfection-is-achieved-not-when-there-is-nothing-more-to https://www.goodreads.com/quotes/19905-perfection-is-achieve... [2] https://quoteinvestigator.com/2012/04/28/shorter-letter/ https://quoteinvestigator.com/2012/04/28/shorter-letter/
- sorokod 8y ago
  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

There is no switch between "brain on" and "brain off", what you describe as "a fundamental property of TDD" to "reduce mental capacity" is just a misunderstanding on your part. > Then something unexplained happens I am not sure why you think this is "unexplained", as it is spelled out in detail in every TDD introductory text. What there is is a switch between (a) trying to get the tests to pass (tests are red) and (b) trying to refactor the code (tests are green). In both cases, you use your full brain, in case (a) you use it to find the minimal code to pass the tests. If you think finding minimal code is a "brain off" activity, well that's a whole different discussion, but I refer you to Saint-Exupéry[1] and Blaise Pascal[2], for starters. And in each case you use code as forcing functions for other code. The tests force you to write the production code. Writing only the least possible production code that passes the tests forces the tests to actually test what you want them to test. If you write code that does significantly more than what your test requires, you won't have test coverage for that excess capability. And so if the rest of your program exercises that excess functionality and you break it, your program will break without your tests giving you a warning. Also, the silliness of the example is of course what makes it a good illustrative example. If we had to first become domain experts with s shared understanding of some random domain, it would make talking about TDD itself much harder. It does require the ability and willingness to use it as an illustrative example. [1] https://www.goodreads.com/quotes/19905-perfection-is-achieved-not-when-there-is-nothing-more-to https://www.goodreads.com/quotes/19905-perfection-is-achieve... [2] https://quoteinvestigator.com/2012/04/28/shorter-letter/ https://quoteinvestigator.com/2012/04/28/shorter-letter/

sorokod 8y ago
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...