TDDを行うとソフトウェアの信頼度が上がる理由

agile

「TDDはテスト手法か否か」の議論で、いまいち私の考えが伝えきれてないようでした(link1, link2)ので、表題にあることを通じて、私のTDDに対する理解の説明を試みます。

用語説明

本題に入る前にこれから使う用語を説明しておきます。
科学的方法には、伝統的な方法としてベーコン由来の実証主義、割と最近のポパー由来の反証主義があります。それぞれ批判はあるのですが、２大潮流といって差し支えないと思います（私は科学哲学については勉強中であり近年の研究はフォローしてないこと、また、観点が反証主義よりなことを、お断りしておきます）。

ここでは、

  • 実証主義……実証の積み重ねから信頼度の高い理論が導けるとする態度
  • 反証主義……様々な反証テストに耐えた理論が信頼度が高いとみなす態度

とします。

先の用語に出てきた、実証、反証とは、

  • 実証……ある理論を経験や実験から真であると証明すること
  • 反証……ある理論を経験や実験から偽であると証明すること

とします。

さらに、

  • 実証テスト……真であることを経験や実験により試みること（例：このパラメータを与えたら期待通りに動くだろう）
  • 反証テスト……偽であることを経験や実験により試みること（例：このパラメータを与えたら期待通りに動かないんじゃないか）

という用語を使用して、テストを二分します。

これらの用語は、かなり噛み砕きましたので、正式な解説は他にまかせますが（プログラミングの文脈に合うもっと良い要約があったら教えてください）、おおよそこういうことだと思ってください。

TDDのプロセスを分析する

TDDのプロセスは一般的には単純化して、

RED　→　GREEN　→　REFACTOR

であるといわれます。

ここでは、先に説明した用語を使って、ソフトウェアのユニットテストレベルの要素を分析すると、

問題に対して、解決方法（理論）であるユニットUが提示され、それに対する実証テストTと反証テストFがある。

となります。

これを援用して、TDDのプロセスを詳細に分析すると、

F1(RED)　→　U1(Write)　→　F1がT1へ変じる(GREEN)　→　U1.1(REFACTOR)　→　T1(GREEN)　→　F2(RED)　→　U2(ReWrite)　→　F2がT2へ変じる(GREEN)　→　U2.1(REFACTOR)　→　T2(GREEN)　→　……以後繰り返し……

となります。
ここでU1とU1.1、U2、U2.1は全て同じユニットです。１つのユニットが次々とブラッシュアップされていく様を表しています。

このように、TDDを行うことにより、実証テスト(T1、T2、…)が次々と積み重なっていきます。ということは、実証主義的にみると、信頼度が高いことになります。さらに、ここで注目したいのは、ユニットが多様な反証テスト(F1、F2、…)を乗り越えてよりよい解決方法（理論）になっているということです。となれば、反証主義的に見ても、このユニット(U2.1)は以前のユニット(U1)に比べて信頼度が上がっていると見ることができます。このようにテスト手法を内蔵してるからこそ信頼度が上がるわけです。

これが、TDDを行うとソフトウェアの信頼度が上がるという理由です。

附則

これをもって、TDDの信頼度が上がるから、他のテストを行わなくても良いということにはなりません。道のりは多めに見てもやっと半分といったところです。また道のりは新たに発見される不具合によって無限に延長されます。先に見たように、TDDでは、大部分が実証テストで構成されており、最終的なユニットに対する反証テストがほとんどありません。ということは、この時点では開発者のドグマに過ぎません。他者の目も借りて網羅的で厳しい反証テストにかける必要があります。また、結合テスト、システムテストといった規模の問題もあります。ゆえに、TDDはテスト手法として見ると不十分です。これが、TDDが一義的には開発手法であり、テスト手法としては二義的に留まると言われる所以です。


まだまだ精進が足りなく、説明がぎこちないですが、リリースして世に問うてみようと思います。