Tracとテストと成果物

システム開発のお客様が開発の成果物として提出を求めるものは、同じようで千差万別な気がします。呼び方は違うけど同じようなドキュメントもあれば、その会社さん独自のドキュメントもあったり。

僕は開発者なので、ひとつの書き方で色々なお客様の要望に応えられる、効率的な方法があったらいいなーと思っちゃって、抽象的な成果物の書き方を、お客様ごとにコンバータを書いて、フォーマットのドキュメントを簡単に作れたらいいかも、と思いつきました。

でも開発する方も実は千差万別で、会社や開発者によって微妙に意味が違ったりすることもあります。一人で開発してたら、上のパターンもうまくいくのかもしれないけど、いろんな考え方の人間が統一されたフォーマットで書き上げるってのは、ちょっと辛いのかなーとも思いました。

こんなこと書いてたら、Martin Fowlerの話を思い出しました。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?ModelDrivenArchitecture
実際、お客様が満足する成果物かどうかはお客様に見てもらうのが一番(・・・とも限りませんが、多くの場合)早いので、抽象的な成果物を記述するよりも実際の成果物を書いた方が良いのかもしれません。


というわけで、やっぱり実行可能なテストをどうにか仕様として扱えるようにしたいと考えなおしました。でも問題点がいくつかあるように思います。

抽象度

自動テストはコンピュータがちゃんとテストできるくらい具体的に記されている方がいいですけど、仕様書は必ずしも具体的に読みたいわけではなりません。大きなシステムになればなるほど、概要で全体像を把握したいという要望はあるはずです。具体的なものを抽象的に表現することが実装できれば、なんとかクリアできるかも。

テストとして描かれる前

仕様にはお客様の要望の変化や外的要因の変化で、変更されていくことがあります。Subversionなどのバージョン管理ツールで、時系列で仕様が変わっていくことは表現できたとしても、なぜそうなったのかをコードの中に表現するのは非常に難しいです。TracなどのBTSと連携する必要があります。RSpecのコンテキストにTracのチケットと関連する情報(チケット番号とか)を記しておいて、何らかのツールでまとめて表示することが可能になったら嬉しいですけど、でもチケットになる前のお客様の声やホワイトボードの絵や、機械が読みにくい資料をどのように関連させるのか、非常に難しいですよね。



何が言いたいのかわからなくなってきました。提出用のドキュメントの作成は漏れや間違いを含みやすい割に、それを機械的にチェックできる仕組みがないので、できるだけ自動生成したいのです。だからコードとして実行されるテストや、Tracから自動生成できたらすごく幸せになれるかなと思ったんです。

ただツールによる生成はたいてい融通が利かないので、それをRailsアプリのようにカスタマイズしやすいフォーマッタを書けたら何とかなるような気がしたんですが、テストやTracのチケットになっていない情報をどうしよう・・・ってところで思考が前進しなくなってしまいました。