Acceptance Tests for Tetris when using Test Driven Development

I want to try to implement the Tetris Game using TDD.

From what I've come to understand when reading Growing Object-Oriented Software, Guided by Tests, I should start by defining what would be my Acceptance tests. If I am right, Acceptance tests when doing TDD are defined just like Use Cases.

It is of great importance to define a good first Acceptance Test that will work as "skeleton" of the App, so it should be kind of simple.

I've choosen the following 2 Acce开发者_如何转开发ptance Tests as my first to implement:

1. The Game starts and the Player closes it.
2. The Game starts and the Player does nothing. He eventually loses.

Are these 2 acceptance tests good starting tests? What would be good next acceptance tests? I could think of something like

• The game starts and only square pieces drop. The player puts them all in such a way that the lines always "explode", making the Game after 100 game-steps still be not over.

but I feel this is kind of awkward, as in a real Tetris game you would always have different pieces falling, and that is what Acceptance Testing should be about.

Also, I feel kind of tempted to just try to implement everything in one go when doing (2), which I think is not one pretends when implementing the second Acceptance Test. I guess the idea would be to only have the game implemented after like 6-7 of them, not on the second. Am I right?

Thanks

---

I would think first about the game field and what it looks like after a number of frames with some defined blocks dropped. For example using Cucumber:

Scenario: dropping the first square
  Given an empty 10x2 field

  When a square is dropped at column 4
  And 48 frames have passed

  Then the field should contain a square at (4, 1)

  When 48 frames have passed
  Then the field should contain a square at (4, 2)

Scenario: Dropping a square on a full stack
  Given an empty 10x2 field
  And a square at (4, 2)

  When a square is dropped at column 4
  And 48 frames have passed

  Then the game should be over

If you like the look of Cucumber feature specs, you might want to try Cuke4Nuke for .Net or Cuke4Duke for Java.

---

You will want to remove the randomness that belongs in your game from your tests. Yes, this means that the test doesn't perfectly duplicate the game, but it also means you have repeatable tests, and that's of greater value. Isolate the differences - pass a PieceProvider into your game; for the real game pass a RandomPieceProvider, but for the tests pass in a SpecifiedPieceProvider. Now you have just a tiny bit of difference between them, but the difference ought to be so small as not to matter; you can still test all other aspects of the game with confidence.

---

Start out with a simple list of blocks. Assuming no player, the blocks will stack up in a certain way and then spill over. Your test fails if the blocks don't stack up right or the program does not detect spill over.