ゲームエンジンでユニットテストを行う方法

残念なことに、適切な単体テストを作成したことはありません。テストが成功した後に破棄する小さな未編成のテストプログラムのみを作成しました。ゲームプロジェクトで単体テストをどのように実行すべきかについて、明確な考えはありません。（私の言語はC ++です。）

エンジンのサブシステムごとに個別のプロジェクトとそれに関連するテストを用意し、実際のエンジンを構築するより大きなプロジェクト/ソリューションを用意する必要がありますか？たとえばevent、エンジンにモジュールがあるとします。どのように処理すればよいですか？

まず、ユニットテストフレームワークが必要です。過去にUnitTest ++とGoogle Testを使用しました。前者は非常に軽量で、後者はより多くの機能を備えていますが、やや面倒です。そのようなことが必要になった場合、Google Mockとうまく統合できます。もちろん、他にも多くのオプションがあります：このリスト（最終的にはUnitTest ++の著者による）やウィキペディアを参照してください。

ユニットテストは、さまざまなシナリオで特定の独立した独立したコード（「ユニット」）にストレスを与えるための集中テストを記述することです。場合によってはすべてを単体テストできますが、通常、100％のカバレッジを達成することは実際的ではなく、特にゲームでは非常に難しい場合があります-レンダラー出力の単体テストが何らかの意味で有用であるかどうかは議論の余地があります関係なく、「真の」単体テスト。

（自動化された）テストは、自動化されていないテストよりも優れていることを覚えておくことが重要です。したがって、テストが「真の単体テスト」ではないという事実を強調しすぎず、単にテストがあることを誇りに思うべきではありません。ユニットテストフレームワークは、テストをパッケージ化し、障害を均一に報告する機能を含むため、通常、より緩やかな「非ユニット」テストの構築にも役立ちます。

古いテストを復活させ、利用可能なフレームワークの1つを使用してテストプロジェクトにビルドすることをお勧めします。すべてを実行する、時々（またはリリースまたは統合ビルドの一部として自動的に）簡単に実行できるものあなたのテスト。役に立つことが明らかになったときに、コードのビットの新しいテストを作成します。たとえば、テストで検出できた微妙なバグを発見した場合、将来追加する可能性のあるリグレッションをキャッチするために追加できます。

ゲームでの単体テストに適しているのは、ほとんどが低レベルのユーティリティコードであることがわかるでしょう。それは大丈夫です-それが壊れた場合、それは多くの上位層を妨げる可能性のある基礎コードです。

コードベースのすべての小さな関数と論理ゲートのテストがないためにプログラマの煉獄に行かないので、テストの作成に必要以上の時間を費やさないでください。そもそもモジュールを作成するのにかかったよりも、モジュールのテストを書くのに一生懸命に考えたり、かなりの時間を費やしたりする必要がある場合は、時間を浪費している可能性があります。単体テスト（一般的にテスト）は、適切に使用して学習するためのツールであり、すべてに対して実行する必要がある面倒な作業ではありません。

ゲーム開発のためのTDDとユニットテストの使用に関する素晴らしいブログ記事がここにあります：http : //gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1

「ユニット」は、テスト可能な最小のコードであり、通常は単一の関数またはクラスです。単体テストは、コードの単位を実行して、意図したとおりに動作することを確認する別のコードです。すべてのケースをカバーするために、単一のコードユニットに多くのテストを含めることができます。

通常、テストはプロジェクトのメインビルドには含まれません。むしろ、すべてのテストコードを含み、すべてのテストを実行して結果を報告するプログラムを生成する、テスト用の個別のビルド構成があります。テストフレームワークは、このためのすべての足場を提供するため、厳密に必要ではありませんが推奨されます。テストにまったく慣れていない場合は、最初に独自のアドホックテスト装置を作成して、発生しているすべてのことを確実に理解することをお勧めします。

テストでできる限り多くのコードをカバーし、自信がないコードに優先順位を付けるか、脆弱で将来の変更によって破損する可能性のあるコードをカバーします。テストは頻繁に、理想的にはコードを変更するたびに実行する必要があります。