Where does test list from in TDD?

[longyue0521]

My English is bad, but I still want learn and talk about TDD.

When I lean TDD, I always failed in "step 0". Because I don‘t have a test cases list like Kent Beck in his book "Test-Driven Development by Example". I read that book many times, but I still don't know :

1. How to convert requirements to test cases list. I understand the logic is that if all test cases in list passed, it means the requirements have been fully implemented. But,how to properly decompose requirements and convert them to test cases?
2. Why pick up test case A is better than test case B in this moment or some point? Someone call this "rerange test cases". I think it means the reranged test cases guides you like a north star to your destination.

Does someone can help? or Could we invite some TDD masters to share their experience with us. Thanks!

[chbndrhnns]

Should we practice on some example?

Given the Leap Year Kata, what is the test list you would propose?

[tedyoung]

This is more about figuring out "what should it do?" And not worry too much about coming up with a list of test cases, getting just one test case is enough to get started.

When trying to figure out the first test case, think about what is the easiest thing to verify or observe. Let's say you're creating a Tic-Tac-Toe game. You could start with the beginning of a game: what can we observe about a new Tic Tac Toe game? This results in:

Given a game of Tic Tac Toe
When we start it
Then the board is empty

Now you can start digging into the details of "what does empty mean?" Lots of choices, but pick one.

Then you can use the Zero/One/Many (Langr/Ottinger) or ZOMBIES (Grenning) to help you decide where to go next. We've done the Zero or "empty" case. Now we can do the One case (i.e., one move):

Given a game of Tic Tac Toe that has started
When a player moves to the upper-left square
Then the board has an "X" in the upper-left square

In terms of "Why pick up test case A is better than test case B", I like to start with the simplest possible case and move small step by small step to more complex cases. Sometimes, it's easier to start with a more complex case and work backwards. For example, you could start with a "win condition":

Given a game of Tic Tac Toe where there is an "X" in the upper and middle square in the first column
When Player "X" moves to the bottom-left square
Then Player "X" has won

Though I think this is harder, sometimes it helps you figure out what tests are missing.

(btw, I have a series of articles on TDD starting here).