C ++ベースのゲームの単体テストフレームワークはどれですか？[閉まっている]

どのテストツールの組み合わせが最適だと思いますか？選択したフレームワーク/ライブラリを考えると、あなたは考慮するかもしれません：

• TDDへの適合性
• 使いやすさ/生産性
• モックオブジェクトを扱う
• 継続的インテグレーションを使用したセットアップ
• エラー報告

注：これは潜在的にSOのような一般的な質問ですが、ゲーム開発は通常、テストの選択に影響する特定のワークフローにバインドされていると主張します。より高いレベルの観点については、質問「ゲームの自動テスト」を参照してください。

私が見つかりました。unittestの++は非常に簡単で仕事にします。私はまだそれと一緒にamopを試してみる必要があります。これは、モックオブジェクト機能のためのUnitTest ++の良い仲間であると述べられました。それ以外の場合は、Google Mockが一般的な選択肢です。また、UnitTest ++およびMock Objectsを参照することもできます。

UnitTest ++は、Hudsonなどの継続的インテグレーションアプローチでセットアップできます。

ユニットテストとゲームがうまくいくと確信していない場合は、この刺激的な投稿をお読みください。

UnitTest ++への別の投票。組み込みが非常に簡単で、ターゲットの組み込みプラットフォーム用にコンパイルされているため、非常に簡単で、簡単で使いやすいです。また、Hudsonと統合しました。GoogleTestを調べましたが、拒否しました（ターゲットプラットフォームでのコンパイルに問題があったと思います）が、同様の機能セットを備えており、あなたに適している可能性があります。

さらに、何らかの煙テストフレームワークを検討することもできます。私の経験では、単体テストだけでゲームを十分にテストすることは困難です。特に、既存のコードベースに単体テストを導入する場合、さらに大規模なチームに導入する場合はなおさらです。煙テストは、「すべてのレベルがロードされることを確認する」などの高レベルのテストです。私の理論では、両方の種類のテストがある場合、ある時点でそれらは中間で会って、まともな収束をもたらすかもしれないということです。:)

C ++で作業していたとき（免責事項：2005年頃）、TUT（テンプレートユニットテストフレームワーク）を少し修正したバージョンを使用しました。とても軽量で、変更が簡単で、テストの作成時に「接着剤」がほとんど必要ないため、私はそれが好きでした。

ここに、私が行った非常に簡単な変更の1つを示します。これにより、テストの作成がより簡単になります。

static int BogusFunction() { return __COUNTER__; } // Increment the __COUNTER__ to the correct position for the begining of the tests
#define TEST template<> template<> void object::test<__COUNTER__>()
#define ENSURE(msg, cond) ensure(msg, cond, __FILE__, __LINE__)
#define ENSURE_EQUALS(msg, actual, expected) ensure_equals(msg, actual, expected, __FILE__, __LINE__)
#define ENSURE_DISTANCE(msg, actual, expected, distance) ensure_distance(msg, actual, expected, distance, __FILE__, __LINE__)
#define FAIL(msg) fail(msg, __FILE__, __LINE__)

私が行ったもう1つの変更は出力形式であり、テストの失敗はVisual Studioのエラーリスト（ビルドの一部として実行される場合）に正しく表示され、クリックして失敗したテストのファイルと行に移動できます。

（この種のことを行う能力は、TDD / CIプロセスに適合するように強制するのではなく、TDD / CIプロセスに適合させることができることを意味します。）

以下にテストの例を示します（エディターのコマンドスタックから）。

TEST // Undoing a command
{
    cs.AddCommand(new TestCommand);
    cs.AddCommand(new TestCommand(od));

    ENSURE("Undo success", cs.Undo());
    ENSURE_EQUALS("Stack size", cs.size(), 2);
    ENSURE_EQUALS("Command's Undo() was called", od.undo, 1);
    ENSURE_EQUALS("Command's Redo() not called", od.redo, 0);

    ACommandStack::const_iterator it = cs.end();
    ENSURE("Command is redoable", cs.GetUndoPos() == --it);
}

（上記のコードで、csおよびodモジュールごとの器具であり、TestCommandモックオブジェクトです。）

C ++に関しては、googletestフレームワークhttp://code.google.com/p/googletest/を試し、使用しました。設定が簡単で使いやすく、優れた機能を発揮します。

私はプロのゲーム開発者ではありませんが、プロの組み込み開発者です。おそらくゲームとまったく同じではなく、近いでしょう。私の職場では、いくつか使用しました。

私は本当にグーグルテストが好きです。最新の単体テストフレームワークのすべての最高の機能を備えながら、最小限のストリームラインインターフェイスですべてを維持します。

リストの次はBoost Testです。GoogleテストのapiはBoost.Testよりも少し現代的ですが、Boost Testは新機能を追加し、粗末なCppUnitパラダイムを捨てるという素晴らしい仕事をしました。

CxxTestも使用しました。非常によくできていますが、Boost.TestやGoogle Testほど最新ではないことがわかります。特に、テストスイートとフィクスチャのサポートは少し厄介です。

私は高度な機能を使用したいのですが、もしあなたがミニマリストなら、3つの違いを目にすることは決してないでしょう。私の同僚の大部分は、自動登録テストをサポートし、ある種のCHECK_EQUALS（a、b）マクロを持つ単体テストフレームワークに満足しています。

私のお気に入りのテストライブラリはQuickCheck http://en.wikipedia.org/wiki/QuickCheckです。実験的なC ++バージョンがありますが、重すぎるように見えますが、専用ライブラリがなくても原則は簡単に使用できます。

すべてのクラスには、ランダムインスタンスを生成できるgenArbitraryメソッドがあります。これは、ロードやアンロードなどの可逆プロセスの煙テストに使用します。数千のランダムシーンを生成し、さまざまなプロパティが保持されていることを確認できます（シリアル化するシーンは、逆シリアル化するシーンと同じです）。

従来の単体テストに取って代わるものではありません（多くの潜在的な単体テストの必要性を減らします）が、バグを発見するのに最適な方法であり、（Valgrindとともに）メモリ割り当て戦略のストレステストに役立ちます。100万を超える割り当てがValgrind pureから出力されるのを見るのは素晴らしいことです:)。

私はCxxTestをテストハーネスとして使用していました。現在、すべてのテストは個別のexeです。Testというフォルダーがあり、Test_で始まるファイルがすべてテストになります。これまでのところ、テストを行うのは本当に簡単な軽量です。

Javaには、非常に多くの優れたライブラリがあります... C ++の場合ではありません。

C ++ユーザーの場合、非常に興味深いキットウェアのチェーンツールがあります。

• CMake：作成ツール
• CDash：継続的統合ツール

キットウェアは、コンピューターサイエンス用のC ++コードを記述します。

個人プロジェクトの場合、Boost単体テストライブラリ（デスクトッププラットフォーム上）を使用します。継続的インテグレーションには、Hudsonを使用します。

• Tomcatへの簡単なインストール
• スクリプト可能

次に、TUT（テンプレートユニットテスト）フレームワークを取り上げます。非常に軽量で非常に柔軟性があり、セットアップも使用も非常に簡単なのは言うまでもありません（1つのヘッダーには、メイン/セットアップコードが少し含まれ、後で24行のテストコードがユニットテストに含まれます）。これをbinfmtc（スクリプトとしてC ++プログラムを実行）と組み合わせて、組み込みソフトウェア開発を含むラピッドプロトタイピング/ TDD /学習テンプレートを大成功に導きました。XMLへの出力が可能なため、Jenkins（CI）やSonarとの一連のプロジェクトでうまく適合しました。