TDDで仕様変更とデバッグをする方法

メソッドX()から処理Bを分離

　TDD（テスト駆動開発）では、仕様変更にどのように対応しているのでしょうか？ デバッグはどうやるのでしょうか？ 答えはどちらも「ゼロから作るときと同様にRED ⇒ GREEN ⇒ リファクタリングを繰り返す」です。今回はそれらについて、修正時に変更するテストケースの数を増やさないための考察も含め解説します。

■はじめに

　この連載の第1回ではTDDの基本を、第2回と第3回とでMSTestとNUnitの使い方を説明しました。ここからは、いわば実践編になります。まずは、避けて通ることのできない仕様変更とデバッグの方法についてです。

■対象読者

TDDに興味をお持ちの.NET Frameworkの開発者。 ■必要な環境

　サンプルコードを試してみるには、C# 2010（Expressで可）とNUnit 2.6が必要です。本稿執筆時点では、下記から入手できます。

C# 2010 ExpressとNUnitの入手先、およびNUnitのインストール手順
C# 2010 Express: Microsoft Visual Studio Express NUnit 2.6: NUnit V2 2.6.0 NUnitのインストール手順: NUnit 2.5 の導入 Step by Step（筆者サイト、旧バージョンでの説明ですが基本的に同じです） ※ Visaul Studio 11 betaでも構いません。その場合は、Visual StudioのIDEとNUnitを統合できます（「Visual Studio 11 betaの単体テスト機能を使ってみよう！」を参照）。



■TDDでは仕様変更やバグをどう扱うのか？

　仕様変更とは、TDDではテストケースの修正・追加です。バグとは、TDDではテストケースの不足や誤りです。

　連載第1回で述べたように、TDDのテストファーストとは、自動化されたテストコードの形でメソッドの外部設計を先に確定させてから、それを満たすようにメソッドの内部設計（すなわち製品コードの実装）を行うことでした。

テストファースト： 外部設計（テストケース） ⇒ 内部設計（製品コード）　仕様変更の場合、新たな仕様を満たすために変更・追加しなければならないメソッドがあります。メソッドの外部設計に対する変更・追加として、仕様変更の内容をブレークダウンできたら、後はそのようにテストケースを変更・追加してテストファーストを実施します。

　バグの場合、そのバグを含んでいるメソッドの外部設計に誤りがあったということです。なぜなら、自動化されたテストコードによって外部設計が記述されているのですから、テストファーストでは外部設計を満たさない実装は存在していないはずだからです。ですから、バグの原因となった外部設計（テストケース）の誤りをまず特定し、修正します。そうしてから、変更・追加したテストケースに通るように製品コードを修正します。

　どちらの場合でも、テストファーストで汚くなったコードはリファクタリングします。まとめると、仕様変更でもバグ修正でも、まずテストケースの変更・追加にブレークダウンし、テストケースを変更・追加してREDになることを確認し、次に製品コードを修正してGREENにし、そしてリファクタリングします。最初にコードを書くときのTDDと同じループを回すことになります。

TDD： RED ⇒ GREEN ⇒ リファクタリング ⇒ （…繰り返し…） 仕様変更・デバッグでも変わらない、RED ⇒ GREEN ⇒ リファクタリングの循環


　それでは簡単なサンプルコードを使って、実際のやり方を見ていきましょう。



■関連記事
Windowsフォームのコントロールを簡単に共通フォーマットで揃える
TDDで仕様変更とデバッグをする方法
独自のドロップダウンウィンドウを持った.NETアプリケーションの作成
市販コンポーネントでアプリをさらに実用的に！　～ComponentOne Studio for Windows Phoneを活用したアプリ例～
既存システムを分析するための考え方と対処法

■記事全文へ