Skip to content

Instantly share code, notes, and snippets.

@aliyome
Last active July 22, 2018 05:59
Show Gist options
  • Save aliyome/587dce3d52936c525474 to your computer and use it in GitHub Desktop.
Save aliyome/587dce3d52936c525474 to your computer and use it in GitHub Desktop.

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の実装にテストコードを書くのはとっても難しいため,単体テストを導入するのであれば,新規プロジェクトから使うことになるだろう.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment