uyota 匠の一手

「Test Driven Development」は「テスト駆動開発」と日本語に訳されている。実はあまりこの訳は好きではない。何故なら、駆動と言う言葉は「動く」と言う意味の言葉なので、Test Driven Development の大切な第一要素を酌み切れていない単語だからである。個人的には「テスト主導開発」や「テスト先導開発」等の方が、手法に沿っていて良いと思う。「主導」の不便なところは「手動」と同じ音なので、混同しやすい所ではある。

さて、「テスト主導開発」や「テスト先導開発」の手順だが、名が体を表す通り、最初にテストを記述する事から始める三段法を取る。

1. テストを記述する。
2. テストを通す。
3. テストが通ったまま、コードを洗練する。

一段目でテストを書き出す。つまり、動作を明記する。二段目のテストを通すのは、それが目的。その為ならば如何なる手段をとっても構わない。どんな悪手も、すべて王道。そして、三段目にて、精錬、精製、熟成させる。

何故、「テスト駆動」ではなく、「テスト主導」、「テスト先導」なのかは、プログラムの動作を明記する所から始める所にある。テストを「駆動」するだけだったら、プログラムを書いた後でも事が足りる。第一の目的は、動作の明記と固定になる。

二段目はさっさと駆け抜ける所だ。目標は、第一段階で決めた入力に対し、所定の出力を返すこと。目標達成の為ならば、固定値を返しても構わない。

三段目は熟成の場。プログラマの好奇心と実力の発揮どころだろう。二段目で、書いた汚いコードが気になる。付け足して増えたテストとコードのお蔭で、コードの質が下がってきて、保守に手間取る。そんなのに対応し、かつ三段の中でも一番力が入るところ。どれだけ力をいれても、第一段で動作を固定し、そこから飛び出なければ安全。安全ベルトを締めているので、意図しない動作の差異を見つけるのは用意。もし、意図しない動作が表に出てしまったら、テストケースの欠如になる。

最初は、テストから書き始め動作を全て決めてしまう開発は何とも息苦しい物だと思った。しかし、テストを一つずつ追加していく行為は、安全ベルトを一本ずつ締めていく操作。安全圏から出るとすぐに感知されて結果に出る。安全圏をしっかりと固めた為に、その圏内での自由度は逆に最大になるのだ。言わば、「テスト駆動開発」は命綱から綯う事から始める開発手法なのだ。