昨年秋に発売されたベック『テスト駆動開発』新訳版の存在に今年7月になってようやく気づき、購入・再読して以来、ユニットテストについてぼんやりと考えています。
初版発売時はその存在に気づかず、しばらくしてから図書館で見つけたのがこの本との最初の出会い。借りて読んで大事なことが書かれていると思いつつ再読もせず、その後偶然入手する機会もあったのですがそのときも再読までは至りませんでした。今回あらためて読みかえす気になったのは、訳が新しくなったということもありますが、なんといっても訳者によって付け加えられた付録C「訳者解説: テスト駆動開発の現在」の存在。原著初版出版(2003年)後のテスト駆動開発にまつわるトピックが手際よくまとめられていて、経過した時間を補って余りあります。
思えばソフトウェアテストとの本格的な出会いはマコネル『CODE COMPLETE』(リンク先の第二版ではなくて最初のほう、アスキー出版局)やバイザー『実践的プログラムテスト入門』(日経BP)といった書籍でした。専任の品質管理・保証部門など望むべくもない業務環境でこれらの書籍から得た知見をどのように活かすかを考えていたところに登場してきたのがJUnitに代表されるユニットテストフレームワークで、その利用はコーディングフェーズでの品質保証・向上におおいに役立ちました(ユニットテストのないプロジェクトにユニットテストを追加していく困難という別の話はありましたが)。
しかしソフトウェアテストの視点でユニットテストを記述するとテストするコードに割く時間・量のほうがテストされるコードよりも多くならざるを得ません。網羅率を向上させるためにはしかたがないのですが、本末転倒感が漂うことも事実。またシンプルなクラス・メソッドをテストするコードの記述はミスを誘発しやすい単純作業に堕しかねないという問題もあります。開発チームと品質保証チームが分かれていれば両者の立場の違いによって緊張が保たれますが、一人でやるとなると緊張を維持するのはなかなかたいへんです(ペアプログラミングだとまた違うのでしょうが、ペアプロ実践など夢のまた夢……)。
ベックの言う「テスト駆動開発」はソフトウェアテストとは異なる視角からのユニットテストの利用です。失敗するユニットテストを書いてからテストに通るアドホックなコードを書き、しかるのちにコードを推敲するという一連の手順はコード記述前の設計の明確化はもとより単純作業化を防ぐ点でも有効に機能するでしょう。
しかし本文中にあるとおり、「皮肉なことに、TDDはテスト技法ではない(Cunninghamの公案)。TDDは分析技法であり、設計技法であり、実際には開発のすべてのアクティビティを構造化する技法なのだ」(p.278)。であればそもそも「テスト」という用語の採用自体が妥当ではなかったと言えるわけで、のちにBDD(Behavior Driven Development, 振る舞い指向開発)という再編成の登場する種はベック自身がまいていたと言えます。Behaviorという表現が妥当かは検討の余地があるとして。
思うに、あるべき姿を事前に具体化して示すことによってかたちをまちがいなく形成するというベックの示した方法論に沿ってユニットテストフレームワークを利用する際は、元の名称にこだわらず「治具」または「型枠」と表現するのが適切ではないかと個人的には考えるのですが、いかがでしょうか。「型枠」ならデザインパターン以来の建築からの用語借用に連なり、「治具」なら英語でも日本語でも略称が"JDD"になる点もポイントです。
治具や型枠が品質保証に充分でないのはむしろ自明。であれば、品質保証のためのテストは分離すればよいわけです。言語や環境によってファイルを分けたりプロジェクトを分けたりやりかたはいろいろ考えられます。ファイルが分かれればコーダーとてスターの共同作業もやりやすくなるでしょう。
個人的にはあわせてDbC(Design by Contract, 契約による設計)が利用できればコーディングレベルでの設計・品質保証の明確化としては充分ではないかと思います。契約による設計は来そうでなかなか来てくれませんが、サポートはじわりじわりと増えつつありますから(たとえそれが表明だけであろうとも)、使える言語・環境であればどんどん使って普及の後押しをしていきたいところです。というかマイクロソフトはCode Contracts for .NETをさっさとVisual Studio 2017対応にしなさい。