テスト駆動開発のスタイル

テスト駆動開発のスタイル

ここで、発想を変えてみましょう。

テストコードを先に書き、ソースコードを後に書くことにしてはどうでしょうか。そして、リファクタリングを後にまわすことにしたらどうでしょうか。さらに一連の作業を最小にして、この3つの作業を繰り返すことにしたらどうでしょうか。

そう、これがテスト駆動開発なのです。具体的なテスト駆動の開発プロセスは表2のようになります。

テスト駆動開発はテストコードを先にプログラミングし、テストを成功させるための対象ソースコードを実装することによって実際のプログラム実装が進みます。いいかえると、テストを成功させるためにテスト対象となるソースコードを実装していくスタイルです。

テストコードを実装しないプログラム実装はなく、テストコードと実際のコードがペアで作成されて、開発が進みます。

最初はテストが失敗し、その失敗したテストを成功させるために最も簡単なコーディングを行います。次に、テストが成功することを確認したら、先ほど作成した簡単なコーディングをリファクタリングし、またテストを成功させます。

テスト駆動開発では、図1に示すようにエラーが起きる状態をレッド（テストがパスしない状況）、そしてテストが成功する状態をグリーン（テストをパスしている状況）というように表現します。つまり「レッド → グリーン → リファクタリング → レッド →グリーン → …」というリズムで開発が進むことになります。
 

図1：テスト駆動開発のリズム

テスト駆動開発を採用すれば、開発者は十分なコードを書いたことを納得できます（だって、テストをパスしたのですから）。

そして、コードは十分に改善／改良されます（だって、リファクタリングという誰でも再現可能な手順で設計を洗練するのですから）。

その上、十分なテストが実施されます（だって、何度も何度もテストを通過していったのですから）。

 

「開発者の視点」から「利用者の視点」へ

先ほど述べた従来の手法は「開発者の視点」でのアプローチであり、テストも「開発者の視点」でテストが行われていました。つまり従来の手法では、開発者が作成したコードに合わせてテストを行うことになります。

ですから、「仕様を満たしているのか」「テストは十分であるのか」と開発者が常に不安を抱えてしまいます。また「開発者の視点」のテストは、「本来の仕様に応えているかどうかの確認にはならない」ということが発生してしまうのです。

しかし、テスト駆動開発は「利用者の視点」のアプローチであり、「利用者の視点」でのテストとなります。

基準となる「テスト（≒仕様）」が成功するように、コーディングを行っていくという形ですから、利用者の要求に応えるスタイルです。よって、コーディング時に仕様に対する品質を作り込むことができます。

さらに、テスト駆動開発はテストの再利用性を考慮していることから、コード修正によるデグレードがないことを確認するためのテストが自動化されているため、開発時に品質を作り込むことができます。

 

テスト駆動開発を実現するVS2005 Team Systemの機能

さて実際にテスト駆動開発を実現するには、ユニットテストを自動実行するツールとリファクタリングを効率よく実施できるエディタが必要です。

 

ユニットテスト機能

テスト駆動開発では、「テストコードを作成すること」「テストを自動化して繰り返し実行できること」「テスト結果を確認すること」をサポートするテスティングフレームワークが必要です。

VS2005 Team Systemでは、このテスティングフレームワークの機能をユニットテストが提供します。

ユニットテストは、テストを実行可能な形で保存しておくことが可能でリファクタリングを行った時に、内部のプログラミング構造が変わっても外部仕様は変わっていないことを再確認できるという利点があります。

さらに、仕様変更などが発生して一部のロジックを変更した場合、保存されているテストを流してみれば、ほかの部分に影響がでていないということやデグレードが発生していないかを確認することができます。

そしてテストケース管理機能を用いれば、個々のテストケースを実行可能な形で管理して必要な時に実行／確認できるということは大変有効といえます。

またユニットテスト、すなわちテスティングフレームワークの機能は、開発者によってバラつきがでるような属人性の排除を可能とするため、品質の均一化がはかれます。同一の尺度での評価が可能となることも大きなメリットです。当然ながら生産性向上にも寄与します。