テストと設計書

出来ることなら全ての設計書は実行可能な形式で書かれるべきで、実行することで何か設計上のミスや不具合を見つけることができて、ソースコードがその設計を正しく反映できているかどうかを確認できるべきだと思います。自動テストがそれに一番近いので、僕はテストケースを書くのが好きです。

しかし、実際テストを書いていくと、どうしても細かいテストが増えます。意図しない動作をしたときには、まずテストを追加することで仕様を確定し、場合によっては修正します。これを繰り返すとどんどんテストは増えていきます。

実行できる仕様という意味ではテストケースのコードは役割を十分果たせると思うのですが、テストケースのコードが増えれば増えるほど、テスト対象の概要を簡単に把握することが難しくなってしまう、というのが最近気になっています。クラス間の相互作用だったり、俯瞰で各クラスの責務の概要を見渡せるような記述はどうしたらいいのかなと。

責務については、例えばメソッド名である程度判断できるようにすることが可能な気がしますが、相互作用については、相互作用を新たに別のファイルとしてテストを書くべきか、それともどちらかのクラスのテストケースに追加するべきか、その場合もう一方のクラスのテストケースからはどのようにリンクするべきかなんて考えてみると、コードの記述だけでなく、もしかしたら開発環境だったりドキュメント生成ツールの話だったりするのかも、とか思えてきました。

チーム内のコードリーディングのスキルに開きがある場合(あるいはコード自身を解説するコメントが効率をあげる場合)、コメントや別のファイルとして実行不可能だけど読みやすい普通の言葉で仕様や設計を書くべきです。その場合何か(仕様/設計/実装)が変更された場合の対象として、コードと同じようにそれらも含める必要があります。