Acceptance Tests for Tetris when using Test Driven Development

Question

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 Acceptance 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

Answer 1

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.

Answer 2

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.