Google Test による C/C++ 単体テスト。 Python unittest パッケージによる単体テスト。 単体テストの約束とガイドライン。

1. 書こう！ 使おう！ 単体テスト
Ryohji Ikebe, December 19, 2021
Google Test と Python unittest での単体テスト

2. プログラムコード
の動きを確かめる
単体テストは何のために？

3. お品書き
単体テストを使うために
❶ Bazel の導入と Google Test での単体テスト
❷ 単体テストの約束
❸ Python unittest パッケージでの単体テスト
❹ 単体テストのガイドライン

4. Bazel の導入と
Google Test での単体テスト
❶

5. 前知識
Google Test: https://google.github.io/googletest/
• 「Bazel でビルド、 Bazel で実行」が唯一の公式サポート
• 「有志」のコントリビューションで CMake もつかえる
• 最新の「全機能」がつかえる保証はない
（不足に気づいたらコントリビュートしよう！）

6. Bazel のインストール
Google による現代的な make 実装：https://bazel.build
• モジュールのビルドやテスト実行のためにつかう
• 以下を bazel.exe として保存しパスを通す：
https://github.com/bazelbuild/bazel/releases/download/4.2.2/
bazel-4.2.2-windows-x86_64.exe
重要：ただしい使いかた、インストール方法は公式を読んでください。
https://docs.bazel.build/versions/4.2.2/bazel-overview.html

7. ワークスペースの設定
WORKSPACEファイル：Visual Studio の .sln ファイル相当
• 開発ターゲットを管理するディレクトリーの最上位に配置
（bazel コマンドは「ここ」をカレントにして実行する）
• 以下内容を WORKSPACE ファイルとして保存：
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "com_google_googletest",
urls = [
"https://github.com/google/googletest/archive/refs/tags/
release-1.11.0.zip"],
strip_prefix = "googletest-release-1.11.0",
sha256 =
"353571c2440176ded91c2de6d6cd88ddd41401d14692ec1f99e35d013feda55a",
)

8. ビルドの準備
BUILD ファイル：Visual Studio の .vcproj ファイル相当
• test ディレクトリーをつくり以下内容の BUILD ファイルを保存：
cc_test(
name = "test",
srcs = ["test.cc"],
deps = ["@com_google_googletest//:gtest_main"],
)
• ここでは test/test.cc のみからテスト実行形式を作成するように指定
• 本来の別実装ファイルをテストする方法は公式ドキュメントを参照

9. テストの実装
test/test.cc
#include <gtest/gtest.h>
namespace {
int factorial(int x) {
auto v = 1;
for (; x; x -= 1)
v *= x;
return v;
}
} // namespace
// Tests factorial of 0.
TEST(FactorialTest, HandlesZeroInput) {
EXPECT_EQ(1, factorial(0));
}
// Tests factorial of positive numbers.
TEST(FactorialTest,
HandlesPositiveInput) {
EXPECT_EQ(1, factorial(1));
EXPECT_EQ(2, factorial(2));
EXPECT_EQ(6, factorial(3));
EXPECT_EQ(40320, factorial(8));
}
https://google.github.io/googletest/primer.html#simple-tests の例を改変して利用。

10. Bazel でのテスト実行
• WORKSPACE のあるディレクトリーで以下を実行：
bazel test //test
• テストディレクトリーでのテスト実行指示（必要ならビルドも走る）

11. 単体テストの約束
❷

12. テストケースの名前: test_xxx
• テストケースの関数名は test_ で始める
• すべてのテストフレームワークの祖先 JUnit からの慣習
• テストケースを「リフレクション」で自動検出するための規約
• リフレクションが使えない C/C++、 Google Test では無用

13. テストケースの本体
テストケースは assertEquals のために書く
• 期待する結果を「表明」する：
assertEquals("hello, world.", get_first_message());
• C言語の assert に似ているが単体テスト専用
• 失敗したら次のテストケースの確認に進む（テストはつづく）
• 言語・テストフレームワークによって様々なバリエーションがある
• フレームワークの仕様・ドキュメントをよく読む
• Google Test は ASSERT_EQ の代わりに EXPECT_EQ を推奨

14. １ケース、１アサーション
• 各テストケースに確かめたい内容をひとつ
• 実際にはいくつ書いてもよい。
しかし、いいテストはシンプルなテスト

15. テストケースの構造
前提のセットアップ、関数呼びだし、アサート
• テストケースは（ただひとつの）アサーションのためにある
テストケースの書きかた：
1. とことん具体的で身もふたもない名前をテストケースにつける
2. アサートする処理（関数）の呼びだしを書く
3. 処理の呼びだしに必要なセットアップをする

16. テストケースに共通なセットアップ
setUp() と tearDown()
• 複数のテストケースで共通する準備は setUp() メソッドで
• 同様にその後かたづけを tearDown() で
• テストケースの呼びだしごとに、その前後で呼ばれる
• Google Test では代わりに Fixture をつかう
https://google.github.io/googletest/primer.html#same-data-multiple-
tests

17. Python
unittest パッケージでの単体テスト
❸

18. Unittest パッケージ
組みこみサポート: https://docs.python.org/3/library/unittest.html
• Python をインストールしたら利用できる！
% python -m unittest
-----------------------------------------------------------
Ran 0 tests in 0.000s
OK
%

19. """test-factorial.py"""
import unittest
def factorial(x: int) -> int:
"""Returns x's factorial."""
return 1
class TestFactorial(unittest.TestCase):
"""Test factorial"""
def test_handles_zero_input(self):
"""Tests factorial of 0."""
self.assertEqual(1, factorial(0))
簡単のため
実装をインポートせず
テスト内で定義
Python 単体テストの書きかた
TestCase クラスを継承し test メソッドを追加する
TestCase を継承
テストケースを
メソッドで実装

20. テストの実行
テストの検索と実行
• unittest パッケージ経由でテスト実装ファイルを実行
% python -m unittest test-factorial
.
-----------------------------------------------------------
Ran 1 test in 0.000s
OK
%

21. 単体テストのガイドライン
❹

22. 条件分岐しない
条件の数だけテストケースを書く
• ある呼びだしで結果が変わり、それを受けて次の処理が……
• テストを分ける
• セットアップで条件を「確定」する
• 「この場合の結果はこれ」というテストケースを量産する
• リファクタリングの際、壊した条件すべてを検出できる
不可！
断じて不可！！

23. ゴールから書く
逆順につくる：アサートから関数呼びだし、そしてセットアップ
1. アサーション（確かめたい結果）からはじめる
2. そのアサーションにたどり着くための関数を呼びだす
3. 関数を呼べるようにセットアップする
新規実装では「使いやすい」インターフェース（API）を設計できる。
理にかなった呼びだし。（テストしやすい＝直感的につかえる）
単純なセットアップ。（呼びだしの手間をとことん削減）

24. 三角測量
関数をふたつ以上のテストケースでカバー
test_double_1_makes_2() = assertEq(2, get_double(1))
• このテストだけでは get_double(_) = 2 という実装の不正を見抜けない
test_double_0_makes_zero() = assertEq(0, get_double(0))
• テストケースがふたつあれば、実装の不正・サボりを見つけやすくなる

25. Python 例のコード修正
• サボっていました。実装を
• 複数のテストケースでカバー
• わかりづらい実装の説明にも
三角測量の実際

26. 単体テストの（真の意味での）単体化
モックオブジェクト、依存関係の抽出
• ネットワークへのアクセス、ファイルシステム、データベース接続、……
• これらを必要とする関数にはその「模倣」オブジェクトの注入で対処
• Dependency Injection, Mock Object
• 例えば：
• ファイル名を渡すのでなく、ファイル内容を渡すようインターフェース変更
• ファイルポインター渡しに変え、テストでは open_memstream に差し替え

27. ビルドへの組みこみ
ビルド後ステップで単体テストを実行
• ビルドとセットで単体テストを実行する
• コードの追加・変更で既存コードを壊していないと確信できる
重要：単体テストの実行時間を短くする。（目指せ！ 全ケース実行１秒以内）

28. テストのリズム ∼ 失敗するテストから始める
フレームワークに保護されていると確かめることから
1. テストケースに assertFail() を書く
• テストして「失敗」する
2. 未実装の関数呼びだしを書く
• ビルドして「失敗」する
3. 「バカ」な実装でアサートを通す
• テストが通る！ やった！
4. バカな実装をつかまえるテストケー
スを追加する
• テストが「失敗」する
5. きちんと実装する
• テストが通る！ かんぺき
『テスト駆動開発入門』

29. 参考（？）： REPL からテストへ
動かせるドキュメントの作成
• これ、どういう動きだったっけ？
• gcc <<EOF -x c && ./a.out
> int main() { …; }
> EOF
• 確認した結果をテストに → 動く（動かせる）ドキュメントに
• 開発者の代わりに利用者が書くテスト

30. まとめ

31. 学んだこと
• Google Test での単体テストの書きかた
• Python unittest での単体テストの書きかた
• 単体テストの約束、ガイドライン

32. 触れ（られ）なかったトピックス
• Visual Studio 2017 以降での Google
Test 統合
• https://docs.microsoft.com/en-
us/visualstudio/test/how-to-use-
google-test-for-cpp
• macOS/Linux での Google Test
• 単体テストチートシート
• アサートのパターン、例外のテスト
• リファクタリングとテスト
• 『リファクタリング』
• 『レガシーコード改善ガイド』
• テストファースト
• 『テスト駆動開発入門』
• その他のテストフレームワーク
• JUnit, CppUnit, …