DRY原則とテストの可読性

DRY原則に従おうとするほど、テストコードがどんどん読みづらくなる。
The RSpec Bookに答えがあるかと思って読んでみたものの、「あるある」と一言述べているだけだった。辛い。
テストコードが読みづらくなる例を示すために、1つRubyのライブラリをつくった。
値とパターンを与えてValidationを行う機能を提供するライブラリ。
実装60行、テスト120行なので、詳しく見たければすぐ読めると思う。
最近不本意ながらキラキラネームの命名力が上がってきたと思う。

avalon - A validator implementation for Ruby
https://github.com/r7kamura/avalon

冗長だが読みやすい例

letもsubjectもローカル変数も何も用いずに率直に書いたテストコード例がこちら。
冗長だが読みやすく、テストコードを見ればライブラリの使い方が分かる。
https://gist.github.com/3595761

冗長ではないが読みにくい例

一方で、出力結果は同じだが、重複を無くそうとした結果読みづらくなってしまったテストコード例がこちら。
新たにテストを追加する場合には楽だが、このテストを見てライブラリの使い方を知るのは苦痛だと思う。
https://gist.github.com/3595759

どうするか

テストでメタプログラミングするのやめろ。
エクセルっぽくなってもいいから馬鹿みたいに分かりやすく書け。
RSpecではオブジェクトの振る舞いのテストに専念しろ。
冗長な実装と仕様を見直せ。
簡単に変わる仕様をつくるな。

最後に

Don't repeat yourself - Wikipediaより、DRYが有用ではない例の1つを引用する。
人間が読むためのテストコードは、より上位の言語から生成されるべきなのかもしれない。

人間が読むことができる文書(コードのコメントから印刷されたマニュアルまで)は、通常はコードの内部まで読んで理解する能力や時間がない人のための推敲、説明を加えてコードの内部にあるものを再度記述している。しかし、DRY では、人間が読むことができるドキュメントはフォーマットの変更を除けば何の価値もなく、すなわち記述されるのではなく生成されるべきとしている。