TDD Is Not An Algorithm Generator(vladimirlevin.blogspot.co.uk)
vladimirlevin.blogspot.co.uk
TDD Is Not An Algorithm Generator
http://vladimirlevin.blogspot.co.uk/2007/04/tdd-is-not-algorithm-generator.html
3 comments
Very important point. It can also be viewed as the difference between research and development. It's hard to get through with testable and measurable development until you've done the fuzzier creative work first.
The "design up front" in TDD is hidden in the write code / refactor steps. The pure TDD framework is bogo-sort for code: start with no code, bang randomly on keyboard, test if it passes, if not then repeat. Obviously something sensible has to go in that gap.
What it usefully replaces is bikeshedding. It lets you try out the design you have in your head, in bite size pieces.
What it usefully replaces is bikeshedding. It lets you try out the design you have in your head, in bite size pieces.
If "the design in your head" involves classes or functions, or any programming language dependent ideas, then it you are not doing TDD. I call this style test-first, or pseudo TDD.
But if the design in your head is an algorithm that can be expressed in natural language, then TDD will let you take that and make a loosely coupled, maintainable program out of it.
Good post on the difference here: http://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-me...
But if the design in your head is an algorithm that can be expressed in natural language, then TDD will let you take that and make a loosely coupled, maintainable program out of it.
Good post on the difference here: http://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-me...
Good holistic take on that article.
Also I applaud Ron for posting an utter failure to get the job done. MANY people run into issues like this (lord knows I have) and documenting it for everyone to see is something we need more of.
Also I applaud Ron for posting an utter failure to get the job done. MANY people run into issues like this (lord knows I have) and documenting it for everyone to see is something we need more of.
This is why I have to watch co-workers create dozens of useless error classes and utility functions, and totally ignore YAGNI, before actually taking a single step towards a working program.
If you don't know the algorithm, and haven't figured out the abstractions, then just slinging some implementation code is the easiest (and laziest) thing you can do. It's basically a way of avoiding having the necessary conversations. In this case, the question that needed answering before beginning TDD was: "How does one efficiently solve a sudoku puzzle (as opposed to just manipulating one)"