Google Test ユーザーが Boost.Test を使ってみた

この記事は、C++ Advent Calendar 2012: 17日目の記事になります。
お題は「Google Test ユーザーが Boost.Test を使ってみた」です。
(2012/12/27: 補足記事を書きました。)

これまで、C++ の testing framework には Google Test を使ってきたのですが、
この機会に Boost.Test に挑戦したいと思います。
今年２月に行われた「Boost.勉強会 #8 大阪」の参加報告で Boost.Test 使うぜ！っと意気込んでおいて今更かという感じではありますが・・・

では、なぜ今まで使わなかったのかというと

• boost の導入がめんどくさそう
• 日本語情報が少ない
• Google Test が使いやすかった

と、いう勝手なイメージがあったからです。最後のが一番大きな理由でした。
でも、他のフレームワークのことも知らずに「Google Test がいいよ！」というのもあれですよね。

それでは、そろそろ本題に入ります。

以下は、今回この記事を書くにあたって参考にさせて頂いたところです。

• Boost Test Library（公式ドキュメント）
• Introduction to boost test
• tonakaiの日記 Boost Testメモ

はじめに

実は、そもそも boost を使ったことありません。
というわけで、まずは boost のセットアップからしました。

開発環境は、Visual Studio 2012 Express 2012 for Windows Desktop です。
boost のバージョンは 1.52.0 です。

～～～略～～～

思っていた以上に簡単にできました！
（本題ではないので別記事にしました。）

include オンリーでも使えた

boost をビルドしたんですが、実はヘッダオンリーでも使えました。
ヘッダオンリーだと気軽に試せるので良いですね！

では、まずはヘッダーオンリーでテストを書いてみましょう。

簡単な例

まずは、簡単なテストから見ていきたいと思います。

#define BOOST_TEST_MAIN    // main関数を定義
#include <boost/test/included/unit_test.hpp>

BOOST_AUTO_TEST_SUITE(sample)

BOOST_AUTO_TEST_CASE(hoge)
{
    BOOST_CHECK_EQUAL(2*2, 4);
}

BOOST_AUTO_TEST_CASE(fuga)
{
    BOOST_CHECK_EQUAL(2*3, 6);
}

BOOST_AUTO_TEST_SUITE_END()

この辺は特に問題ないですね。
BOOST_AUTO_TEST_SUITE でグループ化できて、BOOST_AUTO_TEST_CASE でテストの中身が書けます。
書いたテストは Boost.Test が自動に検出して実行してくれます。
ちなみに、BOOST_AUTO_TEST_SUITE は必須ではありません。

Google Test と比較してみました。

Google Test

//

TEST(sample, hoge)
{
    EXPECT_EQ(2*2, 4);
}

TEST(sample, fuga)
{
    EXPECT_EQ(2*3, 6);
}

//

Boost.Test

BOOST_AUTO_TEST_SUITE(sample)

BOOST_AUTO_TEST_CASE(hoge)
{
    BOOST_CHECK_EQUAL(2*2, 4);
}

BOOST_AUTO_TEST_CASE(fuga)
{
    BOOST_CHECK_EQUAL(2*3, 6);
}

BOOST_AUTO_TEST_SUITE_END()

テストスイートが Google Test における TestCase に、
テストケースが Test(Info) にあたる感じです。

アサーション

値が等しいか検証する BOOST_CHECK_EQUAL など基本的なアサーションはそろっています。
どんなアサーションがあるかは、Boost.Test のリファレンスを参照してください。
（BOOST_CHECK_EQUAL_COLLECTIONS は Google Test にはないアサーションでイイなぁーと思いました。）

また、 Boost.Test のアサーションにはレベルが３種類あって、REQUIRE,CHECK,WARN が使えます。これらのレベルのことを Boost.Test ではフレーバー(flavor)といいます。

Google Test	Boost.Test	エラーカウント	テストの実行
ASSERT	REQUIRE	増加	中断
EXPECT	CHECK	増加	継続
---	WARN	そのまま	継続

(※ Boost.Test の中断は例外を使ったテストの中断、Google Test は return 文でのテスト関数の中断)

Google Test には WARN フレーバーがありませんが、コードを加えることで対応可能です。
詳しくはこちらを参考にしてください。
ブログズミ - Google Test で Boost.Test の WARN flavor を実現する

あと、大事な点を注意書きで済ませてしまってますが、まぁそこは気をつけてくださいってことで。

グループ化

先の説明で Boost.Test のテストスイートが Google Test の TestCase にあたると書きましたが、Boost.Test では namespace のように BOOST_AUTO_TEST_SUITE を複数ネストして使えます。
これは Google Test ではできないことです。

BOOST_AUTO_TEST_SUITE(sample)

BOOST_AUTO_TEST_SUITE(group1)

BOOST_AUTO_TEST_CASE(hoge)
{
    BOOST_CHECK_EQUAL(2*2, 4);
}

BOOST_AUTO_TEST_SUITE_END()

BOOST_AUTO_TEST_SUITE_END()

テストフィクスチャ

Boost.Test でもテストフィクスチャが使用できます。
テストフィクスチャはグローバル、テストスイート、テストケースの３箇所で設置できます。
テストフィクスチャの役割は、主に

• テスト開始前のセットアップ
• テストに関する特定の状態の提供
• テスト終了後の後片付け

の３つです。

この辺は Google Test と変わりませんが、テストフィクスチャの構成や挙動に違いがあるので下記サンプルで説明していきます。

struct Fixture1 {
    Fixture1() : fix1(1) { ::std::cout << "F1 ->" << ::std::endl; }
    ~Fixture1() { ::std::cout << "<- F1" << ::std::endl; }
    int fix1;
};

struct Fixture2 {
    Fixture2() : fix2(2) { ::std::cout << "F2 ->" << ::std::endl; }
    ~Fixture2() { ::std::cout << "<- F2" << ::std::endl; }
    int fix2;
};

struct Fixture3 {
    Fixture3() : fix3(3) { ::std::cout << "F3 ->" << ::std::endl; }
    ~Fixture3() { ::std::cout << "<- F3" << ::std::endl; }
    int fix3;
};

BOOST_GLOBAL_FIXTURE(Fixture1);

BOOST_FIXTURE_TEST_SUITE(sample, Fixture2)

BOOST_FIXTURE_TEST_CASE(hoge, Fixture3)
{
//  BOOST_CHECK_EQUAL(1, fix1); // グローバルはできない？
//  BOOST_CHECK_EQUAL(2, fix2); // Fixture2 は適応されないみたい
    BOOST_CHECK_EQUAL(3, fix3); // フィクスチャメンバーにアクセスできる
}

BOOST_AUTO_TEST_CASE(fuga)
{
//  BOOST_CHECK_EQUAL(1, fix1);
    BOOST_CHECK_EQUAL(2, fix2);
    ++fix2;
}

BOOST_AUTO_TEST_CASE(bar)
{
//  BOOST_CHECK_EQUAL(1, fix1);
    BOOST_CHECK_EQUAL(2, fix2);
    ++fix2;
}

BOOST_AUTO_TEST_SUITE_END()

まず、挙動に関してです。

テストケースでは、テストフィクスチャの状態（メンバー）にアクセスすることができます。
しかし、複数のテストフィクスチャは適応されないようで、BOOST_FIXTURE_TEST_CASE(hoge, Fixture3) では Fixture2 が実行されないようです。
当然、Fixture2 の状態にもアクセスできません。

また、fuga, bar のテストフィクスチャである Fixture2 もテストケース毎に生成/削除されるようです。

Google Test ユーザーとしては、最初「？」となりました。
この辺は実際の出力をご覧ください。

（※ --log_level=test_suite で実行）

続いて、構成です。

	Google Test	Boost.Test
グローバル	::testing::Environment	BOOST_GLOBAL_FIXTURE
テストスイート毎 （テストケース毎）	::testing::Test::SetUpTestCase, ::testing::Test::TearDownTestCase
テストケース毎 （テスト毎）	::testing::Test::SetUp, ::testing::Test::TearDown	BOOST_FIXTURE_TEST_SUITE BOOST_FIXTURE_TEST_CASE

（※ （）書きは Google Test の場合）
（※ SetUp/TearDown に着目した表です。）

Boost.Test の場合、どこでも同じテストフィクスチャを使えますが、
Google Test の場合は、それぞれ書き方が違います。

同じテストフィクスチャでも Google Test と Boost.Test で大分異なりますね。

型をパラメータ化したテスト

複数の型に対して、同様のテストを書きたい場合の方法です。

(Boost.Test Example)

typedef boost::mpl::list<int,long,unsigned char> test_types;

BOOST_AUTO_TEST_CASE_TEMPLATE( my_test, T, test_types )
{
    BOOST_CHECK_EQUAL( sizeof(T), (unsigned)4 );
}

型リストには boost::mpl::list を使います。
この型リストの分だけテストが実行され、型は第二引数に指定した名前で参照します。

実行結果がこちら。

（※ --log_level=test_suite で実行）

型リストの分だけテストが実行されていることがわかると思います。
このように template 関数やクラスのテストを書くにあたって、型のパラメータ化テストが使えるとテストを非常に簡潔に書くことができます。

値をパラメータ化したテスト

Boost.Test に値のパラメータ化テストはない？
あって不思議じゃないんですが･･･リファレンス眺めた感じだと見あたらなかったです。

2012/12/20 追記：私の目が節穴だったようです。すみません。m(__)m

値のパラメータ化ありました。
リファレンスはこちらです。

実行時オプション

Boost.Test でもコマンドライン引数でテストの挙動を実行時に変更できます。
（※ 環境変数でも可能。詳しくはリファレンスを見てください。）

	Google Test	Boost.Test
テストのリスト表示	gtest_list_tests
テストの選択	gtest_filter=[filter]	run_test=[filter]
無効テストの実行	gtest_also_run_disabled_tests
シャッフルテスト	gtest_shuffle	random=[0|seed]
乱数シード	gtest_random_seed=[seed]	random=[seed]
繰り返しテスト	gtest_repeat=[count]
失敗時ブレークポイント停止	gtest_break_on_failure
失敗時例外throw	gtest_throw_on_failure
ログレベル		log_level=[level]
レポートレベル		report_level=[no|confirm|short|detailed]
ログフォーマット	(gtest_output=xml[:path])	output_format=[HRF|XML] report_format=[HRF|XML]
色付き出力	gtest_color=[yes|no|auto]
テスト時間出力	gtest_print_time=[0|1|auto]
プログレス表示		show_progress=[yes|no]
？		auto_start_dbg=[yes|no]
ビルド情報の出力		build_info=[yes|no]
？		catch_system_errors=[yes|no]
framework での例外キャッチ	gtest_catch_exceptions=[0|1]
メモリリーク検出		detect_memory_leak=[0|1|value > 1]
？		detect_fp_exceptions=[yes|no]
？		use_alt_stack=[yes|no]
終了コード		result_code=[yes|no]
ヘルプ	help	help

（※ 各オプションの前に "--" が必要です。）

ぱっと見ただけでも、Google Test と Boost.Test でできることが違うのがわかります。
テストの選択やシャッフルテストはどちらも使えます。これは欠かせない機能ですね。
使い方がよくわからなかったオプションについては「？」としています。これは Boost.Test をもっと使っていけば分かるようになるんでしょう（きっと）。

Boost.Test ではログの出力レベルを細かく設定できます。その詳細です。
--log_level=test_suite はテストスイートの情報が表示されます。↑のサンプル画像を撮る際に使いました。

Value	内容
all	すべて表示
success	all と同じ
test_suite	TestSuite のメッセージを表示
message	ユーザーメッセージを表示
warning	警告レポートを表示
error	エラーレポートを表示
cpp_exception	キャッチされなかった例外を表示
system_error	致命的でないシステムエラーの表示
fatal_error	致命的なエラーの表示
nothing	なにも表示しない

（※ 太字がデフォルト設定になります。）

Google Test の場合はログレベルの概念はありませんが、イベントリスナーをユーザーが定義することで独自の出力をさせることができます。
カスタムイベントリスナーの例はこちらを参照してください。
ブログズミ - Google Test で成功時のメッセージを非表示にする方法

テストレポート(XML)

Boost.Test の結果も Jenkins に集計させることができます！
個人的にこれがあるかないかで評価が大分変わってきます。

Google Test とは少し設定方法が違うので簡単に紹介をします。
Boost.Test で XML を出力するには、「--output_format=XML」オプションでできました。
また、Jenkins でのレポートの集計には、xUnit Plugin を使用します。
Jenkins の設定は Wiki を参考にしてください。

１点だけ注意。

--output_format=XML --log_level=all --report_level=no

Jenkins で集計してもらうためには、ログレベルなどのオプションも必要になります。

集計した結果はこんな感じで見れます。

イイ感じ！

ライブラリ版を使ってみる

ここまでヘッダーオンリーでテストを書いてきましたが、実運用で Boost.Test を使用する場合は Dynamic Library か Static Library を使うことをオススメします。ヘッダーオンリーでは、ソースファイルの分割ができないのと、コンパイルに時間がかかるからです。

ヘッダーオンリーからライブラリを使うように変更するのは簡単です。
まず、インクルードするヘッダーファイルを、
boost/test/included/unit_test.hpp から
boost/test/unit_test.hpp に変更します。
次に、[ライブラリディレクトリ]にビルドした boost の lib ファイルのあるパスを追加します。
リンクは unit_test.hpp でしてくれるので、あとは普通にビルドするだけです。

せっかくなので、ビルド時間を比較してみました。

struct Fixture1 {
 Fixture1() : fix1(1) { ::std::cout << "F1 ->" << ::std::endl; }
 ~Fixture1() { ::std::cout << "<- F1" << ::std::endl; }
 int fix1;
};

BOOST_AUTO_TEST_SUITE(GROUPNAME)

BOOST_AUTO_TEST_SUITE(a)

BOOST_AUTO_TEST_CASE(X)
{
    BOOST_CHECK_EQUAL(2*3, 6);
}

BOOST_AUTO_TEST_CASE(Y)
{
    BOOST_CHECK_EQUAL(2*3, 6);
}

BOOST_FIXTURE_TEST_CASE(Z, Fixture1)
{
    BOOST_CHECK_EQUAL(2*3, 6);
}

BOOST_AUTO_TEST_SUITE_END()

BOOST_FIXTURE_TEST_SUITE(b, Fixture1)

BOOST_AUTO_TEST_CASE(X)
{
    BOOST_CHECK_EQUAL(2*3, 6);
}

BOOST_AUTO_TEST_CASE(Y)
{
    BOOST_CHECK_EQUAL(2*3, 6);
}

BOOST_AUTO_TEST_SUITE_END()


typedef boost::mpl::list<int,long,unsigned char> test_types;

BOOST_AUTO_TEST_CASE_TEMPLATE( my_test, T, test_types )
{
    BOOST_CHECK_EQUAL( sizeof(T), (unsigned)4 );
}

BOOST_AUTO_TEST_SUITE_END()

上記コード x N個 (プリプロセッサで増やした) ものを
Windows7, メモリ: 4GB, CPU: Intel Core i3 2.53GHz, Visual Studio 2012 Express 2012 for Windows Desktop
でビルドしました。

結果

N	インクルード	ライブラリ
10	00:00:16.88	00:00:05.44
100	00:00:20.33	00:00:11.00
1000	00:04:04.31	00:03:52.23
5000	error C1060: ヒープの領域を使い果たしました。 error C1001: コンパイラで内部エラーが発生しました。	02:04:23.22
10000		error C1060: ヒープの領域を使い果たしました。 error C1001: コンパイラで内部エラーが発生しました。

(※ /bigobj オプション付き)

テスト数に関係なくライブラリを使った方が、10秒ちょっと早い結果になりました。
もっと差が出るものかと思ったのですが…検証コードが良くなかったのか？

まとめ

まだまだ Boost.Test を説明しきれていないですが、
冒頭の Boost.Test を使わなかった理由がどのように変わったかで、まとめにしたいと思います。

• boost の導入がめんどくさそう
  とても簡単に導入できました。
  ヘッダオンリーでも使えるので、試しに使いたい人はダウンロードするだけですぐに使えます。
• 日本語情報が少ない
  この記事を書いているときに検索した感じでは、少なくはなかったです。
  ただ、もっと「ここがスゴイ！便利だ！」って感じの記事があるといいかもしれませんね。
• Google Test が使いやすかった
  個人的にはやっぱり Google Test がいいなと思いました。
  理由としては値のパラメータ化テストとテストの繰り返し実行、失敗時ブレークポイント停止がないのが大きいです。特にテストデータをランダム生成して --gtest_repeat=-1 --gtest_break_on_failure で失敗するまでエイジングする使い方をよくするので、それができないのが残念です。
  

最後に

なんだかまとまりのないブログになってしまいましたが、最後までお付き合い頂きありがとうございました。
内容に間違いなどありましたら、コメント下さい(^^ゞ

最後に宣伝。
オレオレテスティングフレームワーク開発中です！
Boost.Test を使ってみていいなと思った機能は自作テスティングフレームワークの iutest に取り込んでいきたいと思います(^^
そして本日、iutest v1.2.0 をリリースしました。


C++ Advent Calendar 2012: 次は、krustf さんで「Cer に知って欲しい C++」です。 →「krustf の雑記」
See ya!