6

TDDを使ってテトリスゲームを実装してみたいです。

Growing Object-Oriented Software, Guided by Testsを読んで理解したことから、受け入れテストとは何かを定義することから始めるべきです。私が正しければ、TDD を行う際の受け入れテストは、ユース ケースと同じように定義されます。

アプリの「スケルトン」として機能する適切な最初の受け入れテストを定義することは非常に重要であるため、単純なものにする必要があります。

最初に実装するものとして、次の 2 つの受け入れテストを選択しました。

  1. ゲームが開始し、プレーヤーがゲームを閉じます。
  2. ゲームが開始され、プレイヤーは何もしません。彼は最終的に負けます。

これら 2 つの受け入れテストは開始テストとして適切ですか? 次の受け入れテストは何が良いでしょうか? 私は次のようなことを考えることができました

  • ゲームが始まり、正方形のピースだけがドロップします。プレーヤーは、線が常に「爆発」するようにすべてを配置し、100 ゲームステップ後もゲームが終了しないようにします。

しかし、実際のテトリス ゲームでは常にさまざまなピースが落ちてくるので、これはちょっと厄介だと思います。それが受け入れテストの目的です。

また、(2) を行うときは、すべてを一度に実装しようとする誘惑に駆られますが、これは、2 番目の受け入れテストを実装するときにふりをすることではないと思います。アイデアとしては、2 回目ではなく、6 ～ 7 回のゲームの後にのみゲームを実装することになると思います。私は正しいですか？

ありがとう

4

3 に答える 3

3

最初にゲーム フィールドについて考え、いくつかの定義されたブロックがドロップされたフレームがいくつかあると、ゲーム フィールドがどのように見えるかを考えます。たとえば、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

Cucumber の機能仕様の外観が気に入った場合は、.Net 用のCuke4NukeまたはJava 用のCuke4Dukeを試してみてください。

于 2010-07-24T11:52:03.323 に答える
2

ゲームに属するランダム性をテストから削除する必要があります。はい、これはテストがゲームを完全に複製しないことを意味しますが、繰り返し可能なテストがあることも意味し、それはより大きな価値があります。違いを分離します-PieceProviderをゲームに渡します。実際のゲームの場合はRandomPieceProviderに合格しますが、テストの場合はSpecifiedPieceProviderに合格します。これで、それらの間にほんの少しの違いがありますが、違いは問題にならないほど小さいはずです。ゲームの他のすべての側面を自信を持ってテストできます。

于 2010-07-24T14:47:23.837 に答える
0

ブロックの単純なリストから始めます。プレーヤーがいないと仮定すると、ブロックは特定の方法で積み重なってからこぼれます。ブロックが正しくスタックしない場合、またはプログラムがスピルオーバーを検出しない場合、テストは失敗します。

于 2010-07-24T07:05:44.283 に答える