xUnit Test Patterns [Chapter12 - Organizing Our Tests]

対象のプロダクトコードに対して、Unit Testが可能な最小単位を「Method」とする。
各「Method」をテストするための「Test method」を複数用意してゆく事になる。
この「Test method」をテストケースと呼ぶ事にする。

これらの「Test method」は当然何らかのクラスに属する事になる。
このクラスを「Testcase Class」と呼ぶ事にする。
各テストケースの入れ物である「Testcase Class」をどういった単位で設けるべきか？

●Testcase Class per Class ・・・ テスト対象のクラスに対して「Testcase Class」を設ける。

• プロダクトコードとテストコードの紐づけが一目瞭然。
• Test methodの増加に伴い、テスト用のクラスが肥大化する。
• 各Test methodが必要とするFixture（Fixture setup）が共通とは限らない。

●Testcase Class per Feature ・・・ 同一のFeatreに属するテストケースをグルーピングする。

• 対象のFeatureに関連する全Testcaseを確認したいといった場合に一目瞭然。
• 各Test methodが必要とするFixture（Fixture setup）が共通とは限らない。

●Testcase Class per Fixture ・・・ 同一のFixtureに属するテストケースをグルーピング。

• Fixture（Fixture setup）が共通。
• 対象のFeatureに対するTestcaseが複数のテスト用のクラスへ分散してしまう

xUnit Test Patternsを読もう

「xUnit Test Patterns」は、書名のとおりxUnitによるテストコードのパターンを解説している書籍。

• マルチスレッドなどテスト自動化が困難なコードに対する対処
• テストケースクラスの粒度
• テストケースクラスのソースコードの構成管理

などなど。単体テストを自動化しようとした場合に直面する問題を解決してゆくためのノウハウが詰まっている。1000ページ近く読み応えがあるので長らく埃を被っていたが、１章ずつ噛み砕いてゆきたい。

ミューテーションテスト

●テストの評価基準

[1] テスト網羅率

• ステートメントカバレッジ (C0)
• ブランチカバレッジ (C1)

⇒テストカバレッジではテスト網羅率の評価のみで、バグ検出能力は評価できない。

[2] バグ検出能力

• ミューテーションテスト

⇒

ソースコードの一部を機械的に変更し、改変されたことをみつけられるかを計測する事で、バグ検出能力を評価する。

サイクロマティック複雑度

循環的複雑度（Cyclomatic complexity）

≒対象関数に分岐がどれだけあるかの度合い

≒C1（分岐網羅）の経路数

if文やfor文のような分岐のないソースコードの場合、複雑度は１。

コードに１つのif文が含まれていれば、コードには2つの分岐がある事になる。

一方はif文での条件が真となる場合の経路で、

もう一方はそれが偽となる場合の経路。複雑度は2。

では、以下のメソッドの複雑度は？

void TestFunc(bool condition1, bool condition2)
{
    if ((condition1 == true) && (condition2 == true))
    {
        std::cout << "Hoge" << std::endl;
    }
}