BLOGcocos2d-xプロジェクトにGoogleTestを導入してみたCocos2d-x2020.01.08夢100事業部でエンジニアをしているmad_khakiです。夢100は「Cocos2d-x」というゲームフレームワークを使って開発しています。今回は「Cocos2d-x」を使ったアプリのプロジェクトにGoogleTestというテストフレームワークを導入し、単体テストを行えるようにする方法を紹介します。Framework」で、Googleが提供しているC++用のテストフレームワークです。iOS向けアプリケーションの開発には必需品であるXcodeの単体テスト機能と組み合わせて使用できる点から選択しました。1.8.1Cocos2d-xのプロジェクトに関しては下記コマンドで新規作成したものをベースに書いていますが、既存プロジェクトに導入することも可能です。テスト用ターゲットの作成ターゲットのテンプレート選択を開くプロジェクトの設定画面の「+」ボタンからターゲットテンプレート選択ウィンドウを開くことができます。Bundle」を選択し、Next右上にあるフィルタ欄にUnitといれると簡単に見つけることができます。U)するとビルドが成功し、サンプルのテストが実行されます。“XXX”」を選択します。targets」は全て解除しておきましょう。追加するとこのようになります。Membershipからテストターゲットを対象にしておきましょう。設定テストターゲットからもCocos2d-xを利用できるようにするために、必要なライブラリを追加します。Cocos2d-xのバージョンによって必要なライブラリは異なるので、ベースプロジェクトの設定を確認しながら設定しましょう。テストを簡単に行えるようにするサンプルのテストの実行結果とソースコードを見ると、テストにはXCTestCaseを継承したクラスを実装するtextXXXとなるメソッドを定義するが必要ということが分かります。1つのテストクラスに、複数のクラスのテストを書くのは避けたいかといって、クラスごとにXCTestC++がメインの開発言語なので、なるべくC++でテストも実装したいといったことを満たすために、xcode-googletestを導入していきます。mattstevens/xcode-googletestGoogleTests.mmは実行時にターゲット内のテストメソッドを収集して実行してくれます。SampleTest.cppを実装してテストを実行すると、これを動的に収集し、テストが行われます。123);}Tests.mmは不要になったので削除してしまいましょう。テストの内容とパラメータを分けて実装できるようにするgoogletestにはTestWithParamというテンプレートクラスが用意されているので、これを活用して、パラメータ化されたテストを行う準備をしましょう。{};実装した基盤クラス(ParamTest)は以下のようになっています。テスト成功時のメッセージTestValueクラスは型を抽象的に扱うためのラッパークラスで、詳細は次の項で解説します。std::mapといったコンテナのwrapperとしてValueクラスが提供されています。型を抽象的に扱うテスト用の拡張を既存のプロジェクトとは分離するという2点を実現しましょう。Valueクラスは継承を想定しておらず、デストラクタにvirtual修飾子がないので追加しておきましょう。~Value();TestValueクラスには各種型に対応したコンストラクタやコンビニエンスコンストラクタを実装します。一部を抜粋したものを掲載しておきます。略テストコードを実装し、実行するテスト対象としてCalculatorクラスを用意しました。bを加算して返すplus関数を持っています。}private:};これに対して、テストコードはこのようになります。これまでの下準備によって、plus関数を実行し、期待値と比較するplus関数に渡す2つの整数と、期待される計算結果を定義するを分離し、1つのテストの中の複数のケースとして実現できています。testing::ValuesIn(testDataList);}()));テストを実行すると、各テストケースが成立していることが確認できます。2つめのケースの期待値(result)を7にするとCalculatorTestの2つめがテストを通過しなくなります。正の数Xcodeのテストレポートからも確認することができます。導入して失敗時の差分を分かりやすくしてみましょう。cubicdaiya/dtlリポジトリからダウンロードし、dtlディレクトリ以下をプロジェクトに追加します。gtest.ccに下記の変更を加えます。msg;テストを実行すると、先程の失敗時の出力がGitのdiffのようになります。(テストファーストなアジャイル型の開発)」にする必要は無いと考えています。プロジェクト開始当初からテスト前提で開発していなければ、そのコードはテストがしやすい作りになっていないことが多く、メンバーもテストに不慣れです。(View)を分離した設計を心がけていないと、更に難度が上がります。いったテスト駆動開発を遵守しようとしてもうまくいきません。テストもテスト駆動開発もあくまで手段なので、使えそうな部分を取り入れていけば良いと思います。エンジニアの自己満足にならず、『より良いプロダクトをユーザに提供する』という目的をブラさずに試行錯誤していきましょう。見つかりませんでした。記事検索Twitterツイート。