チームでの開発では、複数人で開発を行う際に、テストの書き方を個々人好きにやっていいというのではなく、書き方の取り決めや指針みたいなものを出すかどうかという話ですね。

大きいプロジェクトの場合

プロジェクトの性質にもよると思いますが、指針を出すプロジェクトは多いのではないかと思います。「⁠ユニットテストはこういった視点でやります」とか、「⁠このようなところは重点的にテストしてください」などというテスト指針は、大きいプロジェクトになればなるほど重要になってくると思うんですね。

また大規模プロジェクトの場合には、そのプロジェクト用のテストフレームワークを作ることもあると思います。JUnitやS2Unitのような汎用的なテストのしくみを拡張して、そのプロジェクトの対象領域に特化したテストクラスや、テストフレームワークを作ることがよくあります。

「プロジェクト用のテスト機構を作りました。使い方はこうです、こういう視点でテストを行ってください」というように、テストのしくみとして縛りを入れるという方式ですね。

しかし、しくみとして縛りを入れるような場合でも、実際にテストのレクチャーですとか、テストクラスのレビューを行い、テストの書き方をある程度均一化していくというようなことを行わなければならない場合も多いでしょう。そういった取り組みをしないでいると、均質ではないテストコードができてしまい、ほかの人のテストが読んでもわからないとか、わからないので放っておかれたままになってしまうというようなことが出てきてしまうでしょう。

大きいプロジェクトになると、書かれるテストの量自体も非常に多くなりますので、そういった規約や規律のようなものは重要になってくると思います。

小さいプロジェクトの場合

では小さいプロジェクトの場合に、どうやってテストの書き方を伝播していくかというと、一つにはペアで作業するいう方法がありますね。

ペアプログラミングするといっても、完全に毎時間必ずペアを組まなければならないというわけではありません。重要なテストを書くときとか、メンバーが新しくプロジェクトに入ってきたときには、必ずペアでテストの書き方を教えて、このプロジェクトではこういうテストの書き方をしています、だからこういうルールに則って、テストを書いていってくださいというような形で、人づてで伝播していくというようなやり方も、小さいプロジェクトでは非常に有効です。

以前私がコーチとして参加していたXPのプロジェクト（チームかくたに）では、完全にペアプログラミングでコードを書いていましたので、基本的に2人以上は必ずそのテストに関与しているということになります。このようなときには、テストの書き方というのは、人づてに伝わっていくというようなやり方でも十分に機能しました。

規模によって結構状況は違うものの、今回の話で一つ言えることがあります。それは、バラバラなテストの書き方をしていると、ほかのメンバーが書いたテストコードを多分読めなくなってしまいますし、多分自分が書いたテスト自身も、後日にはきっと読めなくなってしまうということです。ですから、テストの書き方の均一性は考えるべき重要な課題なんです。