Hokkaido.pm #11に参加した報告とTestとDocumentの甘い関係に関して
Hokkaido.pm #11に参加してまいりました．
以下が僕の発表スライドです．
Hokkaido.pm #11 from moznion
言いたいことは大体スライドに書いてある通りで，
- TestとDocumentは同じ方向 (どちらも正しいソフトウェアの動作について論じている) を向いている
- 従って協調できるのではないか
- 協調するメリット
- Documentの不整合や陳腐化を防げる
- DocumentとTestをそれぞれ別個に書くよりもコストを低減出来るかもしれない
- 方法は2つあると思う
- Documentにテストケースを埋め込む方法
- TestからDocumentを生成する方法
という感じです．
“TestとDocumentを同居させる方法”というのは割と以前からある考え方っぽくて，PythonではDoctestというテストモジュールが一般的なようですし*1，JavaScriptにおいてはpower-doctestという大変クールなテスティングフレームワークが開発されています．
PerlにもTest::Inlineという似たような働きをするモジュールがありますが，こちらは毎回毎回*.pmファイル (つまりドキュメント) をTestスクリプトに変換してからテストを走らせなくてはならなかったりしてお手軽感が薄い感じです*2．こうした用途で他の言語のモジュールと使い勝手を合わせるとするならば，ドキュメント自体がRunnableかつTestableである必要があるのでは無いかと考えた次第です．
Documentを書けば書くほどテストケースが増えていくというのは割と良いのではないかと思いました．
“TestからDocumentを生成する方法”はかなり良いのでは無いかなと思っています．
Testによって正しい動作が保証されているものをそのままDocumentにすれば，その生成されたDocumentの内容ももちろん正しいはずです．
更に，Testを走らせるたびに正しいDocumentが生成・更新されるというのは，スピードの早い開発において後回しにされがちなDocument作成作業を気にしなくても良くなるということになります．CI環境が整っていれば，CIに通るたびに最新かつ正しいDocumentの存在が保証されるというのはコスト的にも心理的にも負担が軽減されるのではないでしょうか．
ただ，この方法がマッチするドメインというのはあまり思いつかなくて，威力を十分に発揮できるのは (Web) APIくらいなのかなぁという感じです．他に何かあったら是非教えて頂きたいです．
今年出てきた，id:r7kamuraさんのautodocの考え方は革新的で非常によいなあと思いました．
「DocumentとTestの協調」は最近個人的にキているので，来年はその辺に注目して行きたい感じです．
最後に北海道の様子をお伝えします．
ラーメン見た
papix papix papix
