Toshiyuki Kawanishi Blog


2008
7 . 3

TDD再考

もうすぐ、WEwLCの第2回読書会です。そこで、前回話題になったテストの定義について理解を深める目的で、Test Driven Development (TDD)について再考してみました。

gihyo.jpには、「[動画で解説]和田卓人の“テスト駆動開発”講座」という記事が掲載されています。そこには以下のような記事があります。
以下、記事からの引用です。


テストという言葉の指すものが広範囲にわたっているため、テスト駆動開発を広めていく上で障害となっている。
テストから連想するものは品質。TDDのテストとは品質とのためのテストではなく、開発を前に進めていくためのはずみ車としてのテスト。
自分の知っている「テスト」という言葉の視点でTDDを見てしまうと、例えば、「このテストで品質が上がるの?」などと言ったように、違うものを同じ言葉で指し示していることで誤解が生じる。


記事では、このような説明の後、テストを以下のように分類してます。
  • Developer Testing
  • Customer Testing
  • QA Testing
Developer Testingとは開発者による開発を進めるためのテスト、Customer Testingとはお客さんによる受け入れテスト、QA Testingとは開発側(開発者もしくは第三者)による品質保証のためのテストのことをいいます。
TDDでおこなうテストは、上記の分類ではDeveloper Testingの中に入ります。つまり、品質を保証するためのテストではなく、開発を安心して効率良く進めるために実施するテストということです。

前回のWEwLC読書会では、TDDのテストはインタフェースのテストというお話をしてくださった方がいらっしゃいましたが、まさしくその通りだと思います。別の言葉で言い換えると、TDDのテストはブラックボックステストだということになります。
ということは、TDDを実行中(?)にコードカバレッジなどの話が出てくるのはおかしいということになりそうです。最近はツールでテストのカバレッジを測ってくれるのであまり意識しないかもしれませんが、ステートメントカバレッジ、ブランチカバレッジなどの技法は、テスト対象のコードのロジックに依存するため、ホワイトボックステストの技法に分類されます。

ホワイトボックスの観点でテストをしてしまうと、内部のロジックを固定することになるので、リファクタリングができなくなってしまいます(もしくはリファクタリング時にテストコードを修正する必要があります)。これでは、TDDの良さが失われてしまいますね。つまり、カバレッジを計測したりといったホワイトボックスの観点を導入するということは、意識しているしていないに関わらず和田さんの仰るQA Testingを実施しているということになるのではないでしょうか。

そこで、今後はDeveloper TestingとQA Testingをしっかり分けて実施することが大切なのではないかと思いました。

とりあえず、以下の方法が思いつきました。
  1. Developer TestingとQA Testingの工程を完全に分ける
  2. 工程は分けられないけど、Developer TestingとQA Testingのテストスイートくらいは分ける
  3. そんな暇はないので、とりあえず、Developer Testingを実施する時とQA Testingを実施する時で頭を切り替える

2くらいから自分で試してみようかなと思います。


(2008/12/11 誤植修正: Thanks to Hayakawaさん)