Testing your code is vital, but you can't use testing as your only tool to produce quality code. I think the parent may have been referring to a scenario like t

Testing your code is vital, but you can't use testing as your only tool to produce quality code. I think the parent may have been referring to a scenario like this [0, 1, 2, 3, 4], where TDD evangelist Ron Jeffries tries to test his way to a sudoku solver. He fails. Why? Because he didn't really stop to gain knowledge of the domain. In plainer terms -- he didn't really have a clue what the problem was, so how could he hope to solve it? Note in his introduction to [2] he says, > I've read a bit more about Sudoku, and even played part of a game. Not the wisest way to go about solving a problem. I do admire his courage in leaving this up all these years though. Compare/contrast with Peter Norvig's sudoku solver[5]. [0]:http://ronjeffries.com/xprog/articles/oksudoku/ http://ronjeffries.com/xprog/articles/oksudoku/ [1]:http://ronjeffries.com/xprog/articles/sudoku2/ http://ronjeffries.com/xprog/articles/sudoku2/ [2]:http://ronjeffries.com/xprog/articles/sudokumusings/ http://ronjeffries.com/xprog/articles/sudokumusings/ [3]:http://ronjeffries.com/xprog/articles/sudoku4/ http://ronjeffries.com/xprog/articles/sudoku4/ [4]:http://ronjeffries.com/xprog/articles/sudoku5/ http://ronjeffries.com/xprog/articles/sudoku5/ [5]:http://norvig.com/sudoku.html http://norvig.com/sudoku.html Norvig tests his code, too, but he begins by seeking to understand the problem, not by writing tests first and hoping to end up with a quality product.