ユニットテストの直交性対ユニットテストの簡潔さ

ビデオゲームのステアリングシステムの単体テストを書いています。システムにはいくつかの動作があります（理由Aのためにこの領域を避け、理由Bのためにこの領域を避けてください。それぞれが領域のマップに少しのコンテキストを追加します。

動作の単体テストの書き方を決めるのに苦労しています。TDDが示唆しているように、私はその振る舞いが望ましい動きにどのように影響するかだけに興味があります。たとえば、avoid-because-of-reason-Aは、悪い位置を示唆する位置からの移動をもたらすはずです。実際には、ビヘイビアーがマップにコンテキストを追加する方法や理由は気にしません。目的の動きが位置から離れているだけです。

したがって、各動作のテストでは、動作を設定し、マップに書き込むようにし、マップ解析関数を実行して目的の動作を実現します。その動きが私の仕様を満たしているなら、私は幸せです。

ただし、現在のテストは、正しく動作する動作と、正しく機能するマップ解析機能の両方に依存しています。解析機能が失敗した場合、数回ではなく数百回のテストに失敗します。多くのテスト作成ガイドは、これが悪い考えであることを示唆しています。

ただし、マップをモックアウトすることで動作の出力に対して直接テストする場合、確実に実装に緊密に結合していますか？わずかに異なる動作を使用して、マップから同じ目的の動きを取得できる場合、テストは合格します。

だから今、私は認知的不協和音に苦しんでいます。これらのテストを構成する最良の方法は何ですか？

理想的な世界では、まったく同じレベルの抽象化で、完全に直交する単体テストのセットが実際にあります。

現実の世界では、通常、アプリのさまざまなレベルでテストが行​​われるため、多くの場合、高レベルのテストは専用の低レベルのテストでもテスト済みの機能を実行します。（多くの人は、単体テストよりもこのような高レベルのテストサブシステム/統合テストを呼び出すことを好みますが、それでも同じ単体テストフレームワーク上で実行できるため、技術的な観点からは大きな違いはありません。）

これは悪いことではないと思います。ポイントは、「理想的な方法」に固執するのではなく、プロジェクトと状況に合った最良の方法でコードをテストすることです。

この種のテストは、モックが発明された理由です。主なアイデア：オブジェクト（マップ、動作、キャラクターなど）のモックを作成し、実際のオブジェクトの代わりにそのモックを使用してテストを作成します。モックスタブと呼ばれることもありますが、両方に別の言葉があると思います。

あなたの場合、振る舞いをテストする必要があるときはいつでもマップのモックを書き、マップをテストするときはいつでも振る舞いの他のモックを書きます。モックは、モックしている実際の動作よりもはるかに単純で、そのテストに実際に必要なメソッドまたは変数のみを組み込むことが理想的です。テストごとに異なるモックを作成する必要がある場合や、一部のモックを再利用できる場合があります。とにかく、それらはテストに適しているべきであり、実際の動作にできるだけ似せようとすべきではありません。

マップまたはビヘイビアのいくつかの例を含めた場合、おそらく誰かが作成できるモックの例を提供できます。私ではなく、Pongよりも高度なビデオゲームをプログラミングしたことがないので、それでも本を追っていましたが、ユニットテストとゲーム開発の両方に精通している人がいるかもしれません。

ユニットよりもはるかに高いレベルのものをテストしようとすると思います。

ほとんどの動作テストでは、正常に動作するかどうかを判断するために、その背後にあるインテリジェンスが必要になります。これは、自動テストを使用して簡単に行うことはできません。