『Selenium デザインパターン & ベストプラクティス』を読んだ。読み進めていくと、Seleniumを使ってテストを書き始め、それを成長させながらパターンを入していくシナリオを追うことになる。ストーリィのあるシナリオに沿って読み進めていけるので、パターンカタログより入りやすい。そう言えば『実践テスト駆動開発』もこの書き方だった。最近、テストコードよりテストデータに関心が向いているので、「4章 データ駆動テスト」はちょっとスピードを落としてじっくり読んでいたように思う。特に、Default Valuesパターンとfakerライブラリに関する記載を、読んでは悩み読んでは悩みを繰り返している。
Default Patternsパターンでは、テストの関心でないデータにはデフォルト値を使う。"xUnit Test Patterns" でいうところのDummy Objectパターンに近いと思う。その利点と欠点は次のとおり。欠点1は比較的軽いと思う。テストヘルパに寄せたり、許容できるレベルまで軽減できる。より深刻なのは、欠点2の方だ。バグを見つけられないリスクが高くなる。
- 利点
- 知る必要があるものだけに知らせる
- テストがシンプルになる
- 焦点を絞れる
- 重要な値だけを上書きする
- 欠点
- 上書きを実装する必要がある
- データが均一になる
そのデフォルト値として実際に入力されそうなデータを使いたい、というのがfakerライブラリのモチベーションのようだ。ここはnullも候補になるDummy Objectパターンとは大きく違う。テストレベルの違いが出ている。
どんなテストであっても、できるだけ実際のシナリオに近い入力データを目指すべきです。テストの関心ではないからテスト設計はしないにしろ、確かにあまりにも非現実的なデータだと、サービス開始直後に足下を掬われるかもしれない。デザインの文脈でいうところの "Lorem Ipsum" のようなものだろう。
本書では触れられていないけれど、fakerライブラリで実際に入力されそうなデータを作る代わりに、実際に入力されたデータ（いわゆる移行データ）を使う選択肢もあると思う。そもそも存在しないとかセキュリティ制約にひっかかるとか、使えない場合も多いだろうけれど、使えるなら実際のシナリオそのものを入力データにできる。
ただ、入力データとして移行データを使おうと考えると、『継続的デリバリー』のこの警告を思い出して、逡巡する。
何よりもまず、プロダクションデータのダンプを取得して受入れテスト用にテストデータベースに投入したいという誘惑に負けないこと。
統制のとれた最小限のデータセットを保守しよう。Selniumの文脈での「入力データ」はデータベースのレコードではなくて画面への入力値だから、直接言及されているわけではない。でも、画面への入力値に移行データを使用するとなると、データベース側もそれに整合させる必要が出てくる。それなら、データベース側も移行データを使用したくなるのは不自然ではない。
「画面からは移行データを入れるのにデータベースには入れないの？」
「移行データを使えるのにどうして使わないの？」
どちらの質問にも明確な答えが出ない。移行データを参考にしたデータセットを保守するのが、現実解だろうか。でも、移行データの品質問題でテストがストップする可能性があるのが悩ましい。
テストデータの管理、難しい。「4.7 まとめ」に書いてあるとおりだ。
正直なところ、テストデータを管理することは、テスト自動化における唯一かつ最大の難作業です。複雑さの観点から見ると、複雑なウェブページ上の要素を見つけることなど、テストデータを扱うことに比べればかわいいものです。テストデータをテスト（あるいは評価）するメタテストが欲しくなる。