- 12.5 テストデータを管理する
- 12.6 データの管理とデプロイメントパイプライン
- 8.5.1 受入れテストにおける状態
テストデータの管理で問題となるのは、1) パフォーマンス、2) テストの分離の2つ。xUTPだとそれぞれSlow TestsとSeparation of Concernsに対応しているように思う。
どちらの問題でも、真っ先に原因として挙がるのがデータベース。ユニットテストならデータベースアクセス移譲先 (デザインパターンDAO相当) をテストダブルで置き換えられる。これはパフォーマンスにも分離にも効く。DBの状態も含めてテストしたい場合、インメモリDB (H2, SQLite, JavaDBなど) を使うこともできる。
データベースに限らず、テストとデータのつながりを管理するアプローチには、次の3つがある。
- テストの分離: 各テスト用のデータは、そのテストからしか見えないようにする。
- 順応型テスト: テストがデータ環境を調べ、実際のデータに合わせて振る舞うようにする。
- テストの順序づけ: テストの実行順序を予め決めておいて、一つ前のテストの出力を次のテストの入力とする。
「テストの分離」のためには、まず
テスト終了時にテスト前の状態に戻すとある。そうしないと、次のテストに今のテストのデータが見えてしまう。ただこれにはオプションもある。『システムテスト自動化標準ガイド』や『実践テスト駆動開発』では、テスト対象が登録したデータはテスト終了時に消さずに、テスト開始時に消すことを勧めている。もう一つの方法は、
データを機能分割すること。これができるかどうかは、テスト対象の特性に強く依存する。
データを分割し、巨大で複雑なデータ構造への依存を減らすには、まずデータを整理しないといけない。著者はこんな風に言っている。
何よりもまず、プロダクションデータのダンプを取得して受入れテスト用にテストデータベースに投入したいという誘惑に負けないこと。
統制のとれた最小限のデータセットを保守しよう。整理の取っかかりとなるのが、次の3種類のデータの区別。
- テスト固有のデータ: 一意でなければならない。テストの分離の手段になる。
- テストが参照するデータ: テストには関係するがふるまいには影響しないデータ。そこら中で使われるマスタデータ類を指していると思う。
- アプリケーションが参照するデータ: アプリケーションを立ち上げるのに必要なデータ。
一言で言うと、正しく動くと分かっている(契約による設計の言葉を使うと、事前条件を満たしている)開始位置を特定し、テスト開始時にその状態を復元する。言ってしまえばこれだけなんだけれど、そのためにはテスト対象とテストデータをよく理解する必要がある。それも一部のテストだけじゃない。うまくテストを分離するには、全体を俯瞰する必要がある。
なお、その開始位置を復元するのには、アプリケーションのAPIを利用するよう勧めている。理由は3つ。
- システムを矛盾した状態に持ち込ませない。
- データベースやAPIのリファクタリングの影響を避けられる。
- APIのテストにもなる。