.NET Tools テスト駆動開発ツール最前線（前編） − .NET用テスト駆動開発支援ツールNUnitの新機能 − （株）ピーデー 川俣 晶 2004/11/06
Page1 Page2 Page3

■チェック・ボックスによるテストの選択

　カテゴリよりもきめ細かく実行するテストを選択するのに便利なのが、GUIテストランナーに追加されたチェック・ボックスである。この機能を使う場合、チェックを入れたテストだけが実行される。ソースの修正とテストを繰り返すような状況で、カテゴリ的には異なっているが相互に関連の深いテストだけを選択的に実行するには便利な機能である。

　以下は2つだけチェックを入れて［Run］ボタンをクリックした例である。

チェック・ボックスにより選択したテストの実行

チェックを入れたテストだけが実行される。ソースの修正とテストを繰り返すような状況で、カテゴリ的には異なっているが相互に関連の深いテストだけを選択的に実行するには便利な機能である。

■明示的な実行が必要となるExplicit属性

　さて次に、テスト結果が無効であることを示す黄色の結果になったテストについて見てみよう。

　まず、テスト・メソッドであるTestByExplicitAttributeメソッドが黄色になった例を見てみよう。このメソッドのコードを見ると、Explicit属性が付加されていることが分かるだろう。

' Explicit属性の使用例
<Category("OtherSamples"), Explicit()> _
Public Sub TestByExplicitAttribute()
  Assert.AreEqual(2, TargetClass1.Sample1(1))
End Sub

　この属性は、明示的に実行されるテストであることを示すために付加される。明示的に実行されるというのは、そのテスト・メソッドを特に指定した場合のみ実行されるということである。実行されなかった場合には、テスト結果は黄色となる

　これは、特定の準備がなければ実行できないテスト（手動で通信相手を起動しておかないと動作しないテストなど）や、あまりに時間がかかり過ぎるテストなどに指定するとよいだろう。また、未完成ですぐテストの対象にするには適さないものに付けてもよいかもしれない。テスト駆動開発的には、テストを通らないものが長期間残ることは好ましいことではないが、現場ではやむを得ずそのような状況が発生する可能性は十分に考えられる。

　Explicit属性が付加されたテストを実行するには、ツリー上でそのテストを選択して実行する、ツリー上でチェックを入れて実行する、そのテストが属するカテゴリを追加して実行する、といった方法がある。

■無視されるテストを記述するAssert.Ignoreメソッド

　もう1つ、黄色の結果になるテストは、テスト・メソッドTestByIgnoreによるテストである。これは、Assert.Ignoreメソッドの呼び出しによって発生させた状態である。

' Ignoreメソッドの使用例
<Category("OtherSamples")> _
Public Sub TestByIgnore()
  Assert.Ignore()
End Sub

　テスト・メソッドの中でAssert.Ignoreメソッドを呼び出すと、そのテストは無視され、結果は緑でも赤でもない黄色になる。メソッドの引数に理由を示す文字列を指定することもできる。

　無視されるテストであれば最初から書かねばよいと思うかもしれないが、これは条件によって呼び出すものと思うとよいだろう。例えば、テストを実行する条件が整っていない場合（例えば、特定のファイルが存在しない、ネットワークに接続できないなど）、テストが実行できなかったという意味で、緑でも赤でもない黄色として状況を伝える価値があるかもしれない。テストの準備が整っていないことは、テストの失敗とは異なることであり、赤で示すのが適切とは限らないというわけである。

　なお、Assert.Ignoreメソッドを呼び出しているテスト・メソッドは、どのような方法で実行しても、結果は常に黄色となる。

　これと似たものに、常にテストを失敗させるAssert.Failメソッドも存在する。以前から同趣旨のメソッドはあるが、これも条件によってテストの失敗が確定する場合に使うと便利だろう。

■名称が変更されたテスト結果判定のクラスやメソッド

　さて、NUnit 2.0の利用者であれば、テスト結果の判定に使用するクラスやメソッドが異なっていることに気付くかもしれない。

　NUnit 2.0で使用されていたNUnit.Framework.Assertionクラスはもはや使われていない。その代わりに、名前の似たAssertクラス（NUnit.Framework.Assertクラス）が使用される。これにより、「Assertion.AssertEquals」というような“Assert”という文字列が2回繰り返し出てくるコーディングと決別することができる。これは、Assert.AreEqualというメソッドに置き換えることができ、“Assert”という文字列の繰り返しがなくなるとともに、コードの長さもやや短くなっている。

　また、判定に使用できるメソッドも増えている。名前の相違は、だいたい見れば分かるだろう。例えば、AssertNullはIsNullに変更されている。

' さまざまな判定メソッドの使用例
<Category("SuccessSamples")> _
Public Sub TestByEtc()
  Assert.IsFalse(False)
  Assert.IsNotNull("Sample String")
  Assert.IsNull(Nothing)
  Assert.IsTrue(True)
End Sub

　ただ分かりにくいのは、引数にBoolean値だけを持つAssertメソッドが、あまり名前に類似性のないIsTrueメソッドに対応することだろう。どちらも、引数がTrueであるかどうかを確認する機能を持っているため置き換えて使用できるが、名前だけ見ると直感的に機能が同じだと気付きにくいかもしれない。また、IsTrueメソッドの逆の機能として、Falseであることを確認するIsFalseメソッドも存在する。

　新規の話題とはいえないが、1つだけ補足的にAreSameメソッドの動作を確認するコードもサンプル・コードに含めてある。これは、同じオブジェクトを参照しているかどうかを判定するもので、同じ内容であるかを判定するAreEqualsメソッドとは動作が異なるものである。

' AreSameメソッドが成功する例
<Category("SuccessSamples")> _
Public Sub TestSuccessByAreSame()
  Dim s As String = "Test String"
  Assert.AreSame(s, TargetClass1.Sample2(s))
End Sub

' AreSameメソッドが失敗する例
<Category("FailSamples")> _
Public Sub TestFailByAreSame()
  Dim s As String = "Test String"
  Dim sb As New System.Text.StringBuilder
  sb.Append(s)
  Assert.AreSame(s, TargetClass1.Sample2(sb.ToString()))
End Sub

　ここでは文字列を扱っているが、同じString型のオブジェクトを比較すれば同じと判定される。しかし、System.Text.StringBuilderクラスのインスタンスにAppendメソッドで追加してから、それをToStringメソッドでString型に変換すると、まったく同じ文字列を含んでいるにもかかわらず、同じオブジェクトにはならない。その結果、これらはAreEqualsメソッドでは同じと見なされるが、AreSameメソッドでは同じと見なされない。このような知識を頭に入れて、この2つをうまく使い分けよう。

■配列比較機能が追加されたAreEqualメソッド

　さて、メソッドは同じでも、そこに新しい機能が加えられているケースがある。AreEqualメソッドには、配列の比較という機能が付加されている。これは、引数に2つの配列を渡したとき、その内容の一致を判定してくれるものである。例えば、上記サンプル・コードでは、Sample3メソッドが0、1、2という3つの要素を持つ配列を返している。それを、間違いなく0、1、2という3つの要素を持つかどうかを、AreEqualメソッドで判定している。

' 配列比較の使用例(成功するケース)
<Category("SuccessSamples")> _
Public Sub TestSuccessByArrayEqual()
  Dim wishArray() As Integer = {0, 1, 2}
  Assert.AreEqual(wishArray, TargetClass1.Sample3(3))
End Sub

　結果画面を見て分かるとおり、別オブジェクトとなる配列を用意して比較しても、要素が0、1、2であれば一致と見なされている。しかし、0、1、3であれば一致とは見なされていない。

■コマンドライン引数によるテスト実行

　もう一点、GUIテストランナーでは、コマンドライン引数でテストが実行できることを補足しておこう。例えば、/runオプションを付けて、以下のようなコマンドを実行すると、指定アセンブリ内のテストが起動直後に実行される。

nunit-gui /run Example001.dll

　ビルド直後に常にテストを全実行するような指定を行う場合に便利な機能かもしれない。

　このように、NUnitでは基礎的な機能の進化も進んでいる。より洗練され、使いやすい方向に進んでいるといえるだろう。

　もっとも、カテゴリ分けができるから時間のかかるテストを書いてもよい、というわけではない。全テストが素早く何回も実行できることが、本来望ましい状態である。

■

　今回は、NUnitの新バージョンNUnit 2.2の新機能について見てきた。次回後編では、特に注目すべきNUnitの新機能「Mockオブジェクト」と、NUnitの利用を強力にサポートする「Test Driven .NET」および「NMock」について解説する。お見逃しなく。

INDEX
	［.NET Tools］
	テスト駆動開発ツール最前線（前編）
	1．プログラム開発の効率をアップするための方法
	2．GUIテストランナーとテストのための新機能（1）
	3．GUIテストランナーとテストのための新機能（2）
	テスト駆動開発ツール最前線（後編）
	1．Test Driven .NETによる統合されたテスト
	2．Mockオブジェクトとは何か− NUnitのMockオブジェクト
	3．より高度なMockオブジェクトを実現するNMock

　

「.NET Tools」

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