このエントリーは、TDD Advent Calendar 2013の参加エントリーです。
前日のエントリーは、moonmileさんによるTDD - ノーマルにMSTestを使おう - Qiita [キータ]でした。
テスト駆動開発(TDD)でよく語られるキーワードに「不安をテストにする」という言葉があります。
これは、どういうことでしょうか。
ケントベックの「テスト駆動開発入門」は、このように述べています。
テスト駆動開発は、プログラム中の不安を管理する方法である。ここで言う不安とは悪い意味ではない。...（略）...道理にかなった不安、すなわち「これは困難な問題だから最初から最後までは分からない」という感覚である。
(「テスト駆動開発入門」まえがきから)
即ち、プログラマがキーボードを打つことを阻害する、「プロダクションコードをどのように書けばいいのかわからない」という不安を、失敗するテストとして表現することで、開発を駆動させる原動力とするということです。
このことは、例えば「カバレッジを100%にすること」「バグが発生したらそれとは別に未検出バグを×件見つけること」といった、開発者に対して品質の責任が過度に押しつけられたことから、プログラマーがテストに対して抱いたネガティブなイメージから脱却し、開発者が行うテストを「開発者の意図を確認する」工程として再定義する意味合いがありました。
ですから、「全てのコードをテストファーストしなければいけない」と自らを縛る必要はありませんが、「自分はこのプログラムに不安を感じないからテストを書かない」ということを、「不安をテストにする」という言葉は意味していません。
ユニットテストに限らず、コンパイル時の検証、静的解析、プロダクションコード内のアサーションやガード節、手動テストなど、あらゆる手段を使って、「自分の意図通り動く」「自分の解した仕様の通り動く」コードを、後行程に引き渡す必要があります。これはプロフェッショナルとしてのプログラマーの責務です。
さて、「不安をテストにする」というキーワードとセットでよく取り上げられる言葉に「TDDのテストは品質保証を目的としない」というのがあります。先の段落で述べたように、TDDのテストの第一目標は、「意図通り動く」ということであって、品質保証を目的としません。ですがそれは、「TDDを行っても品質は保証されない」とか、「TDDの段階だからバグがあって当然」ということではなく、品質保証の出発点に立つ、という意味があります。「プログラムが開発者の意図通りに動く」ことを確認できていないプログラムを後工程(テスト工程)の品質保証(QA)がどれだけ頑張っても品質は確保できません。
ということを書くと、TDDとはストイックなのだというニュアンスに受け取られるかもしれませんが。私がTDDで実現したいことは、「プログラマーが、プロフェッショナルとしての喜びを感じることが出来る」現場を作りたい、ということです。そしてその喜びは、自分の意図した通りに動くプログラムが、後工程でブラッシュアップされて、システムとして組み上がって、ユーザーの元にデリバリーされること、そしてその中で、自分の専門性が確かに活かされるということが実感できることです。
Enjoy Testng!
