[garybernhardt]

I'll think about it. With the awful response from Reddit [1], I'm not sure that I want to make another go at it. :) We'll see.

To respond to your example, I'd almost certainly go with something like your Count_Xs_in_Row path, or some similar subset of the problem. I'd probably first drive out the "win" concept by saying "if there's a row full of Xs, X wins; if a row full of Os, O wins." I don't actually need to be able to count rows for that; I can pass something fake in (probably a stub). Once I'd done that, I'd drive out the row counting, possibly backporting that into the "win" tests, but probably leaving them totally isolated.

In this example, the key insight is that the concept of winning (a full row) can be independent of the process of counting rows. The tests would push you toward that separation naturally, because it would be too hard to think about testing the "X wins" directly based upon a full board.

This is still a bit overwrought, as it's still a toy example. Toy examples make TDD sound silly, which is a big part of its perception problem. I still don't know how to fix that other than pairing with a person and/or talking directly to them in person for a couple hours. :(

[1] http://www.reddit.com/r/programming/comments/a2yhe/im_not_su...