Comments on: State Makes It Easy: a Test-First Parable

By: Just passing through | My Other Pants

Just passing through | My Other Pants — Sun, 15 Nov 2009 23:33:15 +0000

[...] now for the punchline. Why do I care? This goes back to the spreadsheet challenge I talked about earlier. I was evaluating my abstract tree and noticed a lot of code that looked like: | Sum(a,b) -> eval a [...]

By: Ball

Ball — Mon, 19 Oct 2009 15:32:11 +0000

Found the sudoku page. Same guy as the spreadsheet challenge. http://xp123.com/xplor/xp0607/index.shtml

By: Ball

Ball — Mon, 19 Oct 2009 13:10:14 +0000

Jon, part of the realization I came to was when some of the TDD proponents began to identify the Sudoku problem as a variation of a basic contraints problem. Once they had that, they then started with a small constrains engine and grew that to a Sudoku board with no issue. I wish I had the link at hand.

The trick is, as far as I can tell, to allow yourself to do research before writing your first test. The selection of the first test is a design decision.

If my spreadsheet’s first test was about how big it is, I’d have used a matrix to store my data. Since the first test was about returning empty when there’s no data, I ended up with a hash to store all my data. the test allowed for a non-existent cell. If you ask how big it is now, I’ll look at the keys to let you know, but it’s automatically sparse.

By: Jon Fuller

Jon Fuller — Mon, 19 Oct 2009 12:55:43 +0000

Thanks Brian! I like your conclusions about test-first being an assumption realizer, and thus making those assumptions explicit.

I’d been thinking about the TDD sudoku problem too, and had come to a similar conclusion about TDD not working for “mathematically important” solutions. So I guess those of us that are “mathematically impaired” will simply not ever find the solution to sudoku. :-/ (I suppose though, like you said, throw enough state at it that I could win, but that sort of defeats the purpose).