Timeline for How to do Test Driven Development
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 24, 2016 at 21:22 | comment | added | Andres F. | @Jules Well... I strongly disagree. I think Jeffries made a fool of himself. "Playing around"... there's no playing around unless it's making stuff that works in some useful or at least interesting way. Jeffries' overvaluing of abstract principles over working software is the antithesis of good design. In the end, he learned nothing about the domain; his "solution" and design are so bad they actually solve nothing. I read his Sudoku articles and they are rambling and boring, and nothing useful can be gleaned from them. Then he realizes it's going nowhere and abruptly stops. Embarrassing. | |
| Jan 24, 2016 at 20:22 | comment | added | Jules | ... Norvig, however, approached the problem as an expository example of standard AI techniques. Both articles ended up with a solution that was better for their own purposes than the other. Jeffries ended up with a better game state representation that would be more resilient to changes in the game rules or more useful if additional features were added (e.g. if an interactive mode were required) while Norvig ended up with a simpler system which demonstrated the standard algorithms he was writing about in his article. | |
| Jan 24, 2016 at 20:18 | comment | added | Jules | @AndresF - I have to say, I wouldn't exactly describe that as a "debacle". The blog post you link is making an apple-to-orange comparison. Jeffries was explicitly playing around in the domain with the intent of finding examples of good OO design. He was also explicitly ignoring common rules of TDD (i.e. "YAGNI") in order to quickly learn about the domain through experimentation ("a Spike"). Furthermore, he explicitly stated that he was more interested in playing with the game state representation than finding an actual solution, because that was more interesting to him. ... | |
| Jan 23, 2016 at 17:21 | history | edited | Jörg W Mittag | CC BY-SA 3.0 |
added 69 characters in body
|
| Jan 16, 2015 at 17:12 | comment | added | Andres F. | @JörgWMittag Correct me if I misunderstood you, but are you saying that Ron Jeffries was doing "pseudo-TDD"? Isn't that a form of the "no true Scotsman" fallacy? (I agree with you about the need for more scientific studies; the blog I linked to is just a colorful anecdote about the spectacular failure of a specific instance of TDD usage. Unfortunately, it seems as if the TDD evangelists are too loud for the rest of us to have a real analysis of this metholody and its alleged benefits). | |
| Jan 16, 2015 at 15:07 | comment | added | Jörg W Mittag |
@AndresF.: Actually, the blog post you linked to seems to echo the experiences Keith made when doing TDD As If You Meant It: when doing "pseudo-TDD" for Tic-Tac-Toe, they start by creating a Board class with a 3x3 array of ints (or something like that). Whereas, if you force them to do TDDAIYMI, they often end up creating a mini-DSL for capturing the domain knowledge. That's just anecdotal, of course. A statistically and scientifically sound study would be nice, but as is often the case with studies like this, they are either way too small or way too expensive.
|
|
| Jan 16, 2015 at 14:48 | comment | added | Andres F. | +1 The answer is good in that it correctly describes TDD. However, it also shows why TDD is a flawed methodology: careful thought and explicit design is needed, especially when faced with algorithmic problems. Doing TDD "in the blind" (as TDD prescribes) by pretending not to have any domain knowledge leads to needless difficulty and dead-ends. See the infamous Sudoku solver debacle (short version: TDD cannot beat domain knowledge). | |
| Nov 20, 2014 at 18:02 | comment | added | Jim Clay | You say "when you force that same group to apply TDD As If You Meant It, they will often end up with a wide diversity of very different designs, often not employing anything even remotely similar to a Board" as if it is a good thing. It is not clear at all to me that it is a good thing, and may even be bad from a maintenance standpoint since it sounds like the implementation would be very counter-intuitive to someone new. Could you explain why this implementation diversity is a good thing, or at least not bad? | |
| Nov 20, 2014 at 13:58 | comment | added | Michaël Le Barbier | A very clear answer indeed! From the practical perspective, a flexible and powerful testing framework is very enjoyable when practising TDD. While independent of TDD, the ability to automatically run tests is invaluable to debug an application. To get started with TDD, non-interarctive programs (UNIX-style) are probably the easiest, because a use-case can be tested by comparing the exit-status and the output of the program to what is expected. A concrete example of this approach can be found in my Gasoline library for OCaml. | |
| Nov 20, 2014 at 11:55 | history | edited | Jörg W Mittag | CC BY-SA 3.0 |
Fix typo and properly mark up the quoted section from the blog post.
|
| Nov 20, 2014 at 11:00 | vote | accept | Yogesh | ||
| Nov 17, 2014 at 10:26 | history | answered | Jörg W Mittag | CC BY-SA 3.0 |