特に大げさな話ではなく。
最近無意識にやっていることに、自分で気づいたのだけど、テストを書いているときに
「条件Aで条件Bで条件~Cのときに結果Xと結果Yになるテストを書きたいんだけど、使えるフィクスチャはないかな。。。あ、あったあった。これを使おう」
これでテストを書くと、そのフィクスチャには、テストと関係ない条件Dと条件~Eが含まれていたりする。後でテストを読んだとき
「ふむ、これだと条件Dの場合になってるが、条件~Dのテストはいらないのかな？」
とか考えがち。あるいはむしろ、条件~Cに意味があることを見落とすのも、怖い。
なので、テストコードをこんなふうにしている。
def test_foo # フィクスチャの準備 assert A assert B assert !C # テスト実行 assert X assert Y end
こう書くことで、フィクスチャにどんな期待をしているかが明示的になる。また、なにかの理由でフィクスチャが壊れて前提条件を満たせなくなったとき、テストが確実に落ちるようにもなる。fail fast の思想である。
テストには仕様を書く。この発想からすれば、まあ当然なのかな。みんなやってるのかしらん。RSpecの人はどうしてるんだろう。
テストに仕様を書くときの問題のひとつが、テストはあくまで「完全に具体的な例」であって、サンプリングにしかならないこと。例にないことは推測するしかないのだけど、推測は誤解のもと。テスト自体を読みやすくする(誤解を避けやすくする)ことは、テストの資産価値を上げるために重要ですね。
あ、あと、そもそも自分がフィクスチャを誤読しちゃったときにも、助けてくれたり。
