TDDと単体テストって別物だよね
仕事で単体テスト仕様書を作っていたのですが、しっかりダメ出しされました…orz
今まで、単体テストなんてxUnitを使ってTDDとか言ってればそれなりのものはできるでしょ♪ぐらいで、真剣に考えたことはありませんでした。けど、今回ダメ出しをされたことをきっかけに、どのようなテストの設計・手法だとプログラムの品質が確保されるかを考えてみることに。
ちなみに、現在はABAP関連の仕事をしているので、xUnitはABAPUnit。残念ながら、ぐぐっても、日本語の関連文献は見つかりませんでした。暇を見つけて、このシリーズの和訳でもしてみようかな…
閑話休題。
巷でよく話題になるTDDは、使い方も含めてそれなりに知識としては頭に入っています。けれど、それをうまく単体テストとして、仕様書に落とし込めないなぁと悶々としていました。
どうゆうことだろう？と調べてみると、以下の記事を見つけました。ちょっと古い記事ですが、2，3年前から本質は変わっていないってことの裏返しですね。
結局のところ，TDDと単体テスト工程でのテストではテストの目的が異なるのである。
Java/J2EE - 【連載◎開発現場から時代を眺める by arton】第2回：ITpro
TDDでのテストの1番の目的は，ある機能を実現するためにはどのようなプログラムの構成が必要かを具体的に考えるためであり，外部からの呼び出しを最初に考えることによって可読性が高いソースを作成するためだ。
一方の単体テストの目的はそのモジュールにバグがないかの調査である。
一行目に、ずばり述べられています。TDDと単体テストは目的が違うものだと。
その違いは、テスト対象のモジュールをブラックボックスとして扱うかホワイトボックスとして扱うかの違いとして出てきます。TDDの概念から言えば、テストを先に作るのですから当然ブラックボックステストになります。ですが、（今の自分のプロジェクトで求められているものは）全ての分岐条件を網羅しているか？といったホワイトボックステストを対象としています*1。
つまり、TDDの概念で考えているとホワイトボックス的なテスト仕様書は書けないということです。自分はその辺を勘違いしてたので、はまってしまってダメ出しをもらいましたと。
分かっている人には今更なのでしょうが、やっぱり机上の知識だけではダメですね。実践で使いこなしていく上で身につけていかないと！
じゃあ、さらに推し進めて。
件のプロジェクトは設計者とPGが完全に分かれており、PGは基本的に設計者が作成した設計書をソースに起こすという役割です。原則、設計（と設計書）はレビュー承認後は変更することができません。*2。これでは、PGが自身でモジュール化等を判断して設計に反映・洗練させていくという、TDDのメリットは享受できません。
TDDと単体テストは違うもので、今回はTDDはやりません。では、TDDで使われているxUnitなどのツールは今回は使えないのか？これは、もちろん使えますよね。
単体テストでのホワイトボックステストの評価としては、命令文や分岐のカバレッジ率があげられます*3。で、カバレッジ率を机上で計算するのもいいけど、こういうのは自動でコンピュータに計算させたいですよね。
そこで、xUnit系ツールと組み合わせて使用する、カバレッジ測定ツールの出番です。@ITでは、Javaでのカバレッジ測定ツールとしてが紹介されています。
結論：
ただ、カバレッジ測定ツールを使う際には、xUnit（今回はABAPUnit）の使用が前提で、その上でカバレッジ測定ツールの使い方も覚えないといけないんですよね*4。けど、最近は終電近くまで残って、やっと割り当てられた作業をこなしているという現状です。この状況じゃ、正直なかなか新しいものに手を出しにくい。
もっと効率を高めて、その浮いた時間でこの辺を試していきたいものです。
