連載：Windowsフォーム開発入門【Visual Studio 2010対応】 Windowsフォームのテスト術 初音 玲 2011/01/12
Page1 Page2 Page3

■単体テストで、Windowsフォームのロジック部をテストする方法

　単体テストを使ってWindowsフォームのロジック部をテストする方法を説明する。

　Windowsフォームのロジックは、ボタンをクリックしたときのClickイベント・プロシージャ内に記述してもコンパイルは通るが、単体テストのことを考えると別のクラスに分離した方がよい。また単体テストがしやすいだけではなく、デザインとロジックを分離した方が全体の見通しがよくなり、デバッグもしやすいという利点もある。

●ロジック・クラスの追加

　まずはロジックを実装するクラス用のファイルを追加する。

　ソリューション・エクスプローラでテスト対象プロジェクトを右クリックして（表示されるコンテキスト・メニューの）［追加］−［クラス］を選択してクラス・ファイルを追加する。

　今回は、そのクラス・ファイルで、IDisposableインターフェイスを実装するPublicなクラスを定義する。

Public Class Calc   Implements System.IDisposable End Class namespace WinFormSampleCs {   public class Calc : System.IDisposable   {   } }

リスト2　ロジック・クラスの例（上：VB、下：C#）

●テスト・コードの記述

　通常は、テスト対象となるコードが先に存在していて、それをテストするコードを後から記述する。しかしそうではなく、先にテスト・コードを記述して、次にそのテストが合格する（テスト対象の）コードを作成していく「テスト・ファースト」という方法論もある。Visual Studioではこの方法論に対応する機能が提供されており、この機能を使えば、先に記述したテスト・コードから、ロジック・クラス内に（テスト対象となる）メンバ定義（＝メソッドやプロパティ）を生成することができる。

　それでは足し算をテストするテスト・コードを記述してみる。

<TestMethod()> Public Sub 足し算検査()   Using _proc As New WinFormSample.Calc     Assert.AreEqual(5, _proc.Plus(2, 3), "足し算失敗")   End Using End Sub [TestMethod] public void 足し算検査() {   using (WinFormSampleCs.Calc _proc = new WinFormSampleCs.Calc())   {     Assert.AreEqual(5, _proc.Plus(2, 3), "足し算失敗");   } }

リスト3　テスト・コードの例（上：VB、下：C#）

　ロジック・クラスであるCalcクラスの中にPlusメソッドが存在しない状態でリスト3を入力すると、Plusメソッドの記述のところでエラーが検出される。そこで次の画面のように、「_proc.Plus」のコード個所に表示されるスマートタグをクリックして、表示されるメニューから［メソッド・スタブの生成］を選択する。

VB

C#

図7　メソッド・スタブの生成（上：VB、下：C#）

　これにより、ロジック・クラスにメソッド・スタブとして「Plus」メソッドが生成される。次のコードは、その例。

Function Plus(ByVal p1 As Integer, ByVal p2 As Integer) As Object   Throw New NotImplementedException End Function public object Plus(int p, int p_2) {   throw new NotImplementedException(); }

リスト4　自動生成されたメソッドの例（上：VB、下：C#）

●メソッド・スタブのテスト実行

　この状態でテストを実行すると、Calcクラスにロジックを記述する前なので、テストは失敗する。

図8　メソッド・スタブのテスト実行

●リファクタリングとロジックの記述

　自動生成されたパラメータ名や戻り値の型が最適なものになっていない場合がある。そこでリファクタリングを行い、最適なものに変更してから、次のようにロジックを記述する。このとき、リファクタリングを行いながらロジックを記述するようなことはせずに、「リファクタリングに集中する時間」と「ロジック記述（および、デバッグ）に集中する時間」というように、それだけを行うようにした方がよい。なぜならば、リファクタリングはプログラムの動きを変えずにプログラムを分かりやすく書き換える作業なので、（それ以外のコーディング作業による影響を排除するために）リファクタリングだけを行うべきだからである。そうしておけば、リファクタリング作業の前後で同じ自動テストを実行することによって、「実施したリファクタリングの結果、意図しない動作変更が発生していないか（＝仕様が変わっていたり、バグを入れ込んでいたり）」を容易にチェックできるようになり、作業効率が高まる。

　次のコード例では、パラメータの名前を「term1」「term2」に、戻り値をInteger型（int型）にリファクタリングした。

Function Plus(ByVal term1 As Integer, ByVal term2 As Integer) As Integer   Return term1 + term2 End Function public int Plus(int term1, int term2) {   return term1 + term2; }

リスト5　リファクタリングしたコードの例（上：VB、下：C#）

　このコードに対してテストを実行した結果は、次のように「成功」になる。

図9　テストの実行

　次のページでは、UIテストを説明する。

INDEX
	［連載］Windowsフォーム開発入門【Visual Studio 2010対応】
	Windowsフォームのテスト術
	1．Visual Studioでの単体テストの基本的な実装方法
	2．単体テストで、Windowsフォームのロジック部をテストする方法
	3．UIテストで、WindowsフォームのUI部をテストする方法

「Windowsフォーム開発入門」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）