AAAパターン
ある単体テストのテストケースが準備(Arrange)、実行(Act)、確認(Assert)の3つのフェーズで構成されていること
準備(Arrange)
事前条件を満たすようにテスト対象システムとその依存をセットアップする
ここで毎回準備している依存はテストフィクスチャとも呼ばれる
3つのフェーズで最も大きくなりがちなので、セットアップ部分を共有コード化するパターンが幾つか知られている
準備が大きくなってきたらテストフィクスチャを生成する関数を作ろう
イミュータブルな依存なら関数ではなくそのまま共有してもいい
実行(Act)
テスト対象システムのメソッドを実行する
実行フェーズは 1 行のコードですまない場合は注意
複数行になることはテスト対象システムで公開されているAPIがきちんと設計されていないことを示唆する
avashe.icon古典学派(単体テスト)は試験が凝集度の高いレベルで設計されていることを望むので、テスト対象システムにもそれを望むことになる?
確認(Assert)
実行の結果を確認する
テスト駆動開発するときは各テストケースの確認フェーズを書くところから始めればよい
アンチパターン
一つのテストケース内にて準備、実行、確認を一度以上繰り返してしまう
準備、実行、確認、実行、確認...のように書かれたテストは複数の事柄を確認しているのであり、複数のテストケースを切り分けるべき
統合テストならあり
if文の使用
途中で分岐する必要がある場合、テストケースで複数の事柄を検証している可能性が高いので複数のテストケースに切り分けるべき
読んだり修正する際の保守コスト増加
類似のものとしてGiven-When-Thenパターンもあるが、本質的な違いはない