ソフトウェアを書いて、手作業でテストする手法とは異なり、テスト駆動開発ではいくつかの規律が求められます。その中で、「テスト駆動開発の経験（6）」で述べたことの一つが「不具合が発生した場合、必ず再現テストを書く」です。

不具合への対処は次のようなステップとなります。

1. 不具合が発生した際に、その原因を調査します（「デバッグの科学的手法」）
2. その不具合を再現させるテストを作成します（不具合が存在するために失敗するテストです）。
3. テストが失敗するのを確認します。
4. 不具合の原因を取り除いて修正します。
5. テストが成功するのを確認します。

マルチスレッドプログラミングでは、原因の調査および再現テストを書くことが非常に困難な場合があります（「マルチスレッドプログラミングにおける重要な４要件」）。その場合の再現テストは、普通の再現テストとは異なる工夫が必要になります（詳細については別の機会に書きたいと思います）。

テスト駆動開発をしていても、原因が分かった時点で再現テストを書くことなくコードを修正する衝動にかられて、コードを修正してしまう開発者も多いのではないでしょうか。実際、再現テストのコードの量よりも、不具合の修正コードの量の方が圧倒的に少ない場合があります。

資産としてのテストを蓄積していくことはテスト駆動開発では重要であり、すべての蓄積されたテストを実行することで、テストがカバーしている範囲の機能が正しく動作しているという安心感が得られます。もちろん、テストに抜け漏れがあるから不具合が見つかるわけですから、新たに見つかった不具合に対して再現テストを書いてさらにテスト資産を蓄積するわけです。その場合、見つかった不具合の再現テストに加えて、類似の原因の不具合があることが分かれば、追加の再現テストも作成して、コードを修正することになります。

再現テストの作成をスキップしがちな場合、意識して再現テストを書く努力をして、「不具合が発生した場合、必ず再現テストを書く」習慣を身につける必要があります。