テストファースト

最近はやりのXPというプログラミングプラクティスがある。開発の現場で利用されているベストプラクティスを集めたようなものであろうか?経験則は必ずしも常に適用可能というわけでもなく、ある前提条件が成り立ったときにのみ効果を発揮するというような類のものなのである。XPの貢献はかつてからプログラミングコミュニティで実践されていたベストプラクティスにわかりやすい名前を付けたことかもしれない。ソフトウェア開発プロセスにおけるプログラムパターンみたいなものであろうか?

テストファーストは先にテストプログラムを作るというような説明を受けているがこの説明はちょっとわかりにくい。実践的なイメージがわかない。新規にプログラムを作るときに先にテストプログラムを書くなんて事を誰がやるのか?そーゆー感じである。プログラマはプログラムを書きたくて書きたくてしょうがないサガを持った人間なのである。そーゆー人間に楽しみを後にして面白くもおかしくもないテストプログラムを先に作れというのは現実的な話なのであろうか?

新規にプログラムを作るときはまあそんな感じもしなくもない。しかし、既存のプログラムの拡張、改良の場合は、テストファーストは思いのほかうまくいく。意識しなくとも結果としてそのようなアプローチをとっている場合もある。

こーゆーシナリオを考えてみよう。あなたはあるプログラムのメンテナである。誰かがバグを報告してきた。あなたが最初にやるべき仕事は、バグを再現するケースを発見することである。バグを報告した人がそのようなケースを提供してくれる場合もある。バグを再現するテストプログラムを作るのである。あなたはそのテストプログラムによって確実にバグが再現することを確認しなければならない。XPのテストファーストなる言葉を知らなくてもあなたは既にテストファーストのプラクティスを実践しているのである。まあ、そーゆーことだ。

経験が浅かったころのあなたは、バグの報告をうけると、再現ケースを作るよりも先に、闇雲にデバッグをはじめなかっただろうか?いきなりコードをハックしはじめなかったか?わたしは、そうだった。問題を正しく理解する前にコードをいじりはじめる。そして何度も何度も痛い目にあって、まず最初にするべき事は問題を正しく理解することだということを学んだ。

正しいテストプログラムを作ることは重要だ。正しいプログラムを作ることと同様にあるいはそれ以上に正しいテストプログラムを作ることは重要である。

そしてこのプロセスを繰り返していくと狭義のバグの修正だけではなくて、機能の拡張、改良にも同様に適用できることがわかる。

Sambaの国際化プロジェクトはまさにテストファーストのプラクティスを適用した。我々が最初に書いたコードは、Sambaを利用する上で不都合がある文字コードを含むテストスクリプトである。ひたすら問題を発見するためにテストスクリプトを書いていったのである。そしていろいろな側面から問題を発見していくことによって、Sambaの実装についての動的な側面からの理解を深めていったのである。問題を正しく理解すれば解決策を見出すことは難しくない。先にテストをすることによって結果としてよりよいコードを作るという副作用も生じるのである。

プロジェクト管理の側面でいうと先にテストプログラムによって問題の個数が明らかになるので、プログラムの実装の進捗が可視化できる。例えばテストプログラムによって100個の問題を発見したとすると、プログラムの実装が進むにつれてどのバグが修正されたか、実装されたかがデジタルにわかるため、プログラムの進捗が誰の目によっても如実に明らかになるのである。

あなたがプロジェクト管理をした経験があるなら、担当プログラマの「実装がだいたい50%完成しました」というような発言になんの意味のないことをよく知っているだろう。その50%というのの意味はコーディングが50%すんだのか?それとも実装は終わっているのだけどテストが50%完了したのか?あるいは単にコンパイルエラーがとれたのか?そもそもどうやって50%進捗したと担当プログラマは報告したのか?その根拠ははっきりいって誰にもわからないのである。それがテストファーストで実装すべき機能についてテストプログラムがあって、それについて実行が成功したか失敗したかが判定できれば、あなたはいとも簡単に定量的にプログラムの開発の進捗を理解できるようになる。進捗を正確にとらえていればあなたはプロジェクトを上手に管理することができるのである。

Does it make sense?