TestDriven.NET(nUnit)試用所見

2012/11/19　　

TestDriven.NET

VisualStudioに統合されたテストスイートアドオン
主な機能
- 単体テスト(nUnit)
- カバレッジ測定(nCover)

VisualStudio2008以降では同等の機能が標準で付属している

デモ

最小限のサンプル

\\krt07001\新電子カルテ開発\05_調査資料\16_作業自動化\ にデモ動画を置いています

テストコードのサンプル

' -----------引数の二乗を計算する関数とテスト-------------

' テストしたいメソッド
Function pow2(ByVal val As Integer) As Integer
	return val * val
End Function

' テストコード
<Test()> _
Sub success_pow2()  '成功ケース
	Assert.AreEqual(100, pow2(10))  ' Equals(期待する結果, 実際の値) '
End Sub
' テストコード
<Test()> _
Sub fail_pow2()  '失敗ケース
	Assert.AreEqual(101, pow2(10))  ' Equals(期待する結果, 実際の値) '
End Sub

サンプルの実行結果

------ Test started: Assembly: Simple.dll ------

TestCase 'Simple.Class1Test.fail_pow2' failed:
  Expected: 101
  But was:  100
	Class1.vb(13,0): at Simple.Class1Test.fail_pow2()

1 passed, 1 failed, 0 skipped, took 0.42 seconds (NUnit 2.4.7).

HOMESの開発で使った場合のサンプルコード

<TestFixture()> _
Class Test_DR0100C0A1

    Dim sut As DR0100C0A1
    Dim refInf As ReferInfo

    ' テスト前に1度だけ行う処理
    <TestFixtureSetUp()> _
    Sub Init()
        ' refInfの準備とDR0100C0A1インスタンスの生成
    End Sub

    ' テスト後に一度だけ行う処理
    <TestFixtureTearDown()> _
    Sub Finalize()
        ' DLL01の終了処理など
    End Sub

    ' 各テストメソッドを呼ぶ前に毎回行う処理
    <SetUp()> _
    Sub SetUp()
        refInf.dllXv.XVFTRSBegin()
        DR0100C0A1.FormLoad();
    End Sub

    ' 各テストメソッド終了時に毎回行う処理
    <TearDown()> _
    Sub TearDown()
        refInf.dllXV.XVFTRSRollBack()
    End Sub

    ' テストメソッド
    <Test()> _
    Sub test1()
        'Testメソッド
        Assert.AreEqual(100, sut.func)
    End Sub

    <Test()> _
    Sub test2()
        'Testメソッド
        Assert.AreEqual("hoge", sut.func2)
    End Sub

    ...

End Class

テスト対象のメソッドは，Public属性にするか，Protected属性にして，テスト対象クラスを継承してPublic属性にラップして利用する．

HOMES開発に使えるか？

「UIテスト」に使うのは難しい
- テストコードが複雑になり，保守が難しくなる -> 本末転倒
- nUnitFormsなどのUIテストツールを使うことで，多少は読みやすいコードが楽に書けるようになる
あくまで「単体テスト」に使うのであれば効果があるが，プログラムの粒度によってはテストコードを書くのが非常に面倒．

ここでの「UIテスト」はHOMES開発で言うところの「単体テスト仕様書」に書くようなテストのことを指す．同様に「単体テスト」は，メソッドレベルでの正当性・信頼性を担保するものを指す．

nUnit(TestDriven.NET)を使うことで生まれるメリット

メソッドレベルの信頼性が担保される
単体テストが義務付けられれば，テストコードを書くためにメソッドが細かく分割される．(1000行を超えるようなメソッドはテストができない・困難なため)
OOPの勉強になる．(OOPでコードを書くことで，テストがより簡単になるため)

nUnit(TestDriven.NET)を使うことで生まれるデメリット

コード量が増える
データモデルに変更が加わる改修があった場合，以前書いたテストコードが使えなくなる可能性が高い
設計せずにとりあえずコードを書く．という作り方ができない

まとめ

　コーディング作業中に単体テストを書く分にはとても便利．UIテストに利用するには効率が悪い．また，単体テストを書くことで，「テスト可能なコードを書く」ことになるため，コードの質向上につながると思う．しかし，現在のHOMESの実装にテストコードを書くのはとっても難しいため，単体テストを導入するのであれば，新規プロジェクトから使うことになるだろう．

aliyome/nunit.md