【入門編】VB.NETでの単体テスト自動化：NUnit/xUnitとMoqを用いたモックオブジェクトの活用法 – Visual Basic (VB / VB.NET)解析バイブル

VB.NETでビジネスロジックを堅牢に！NUnit/xUnitとMoqで外部依存を切り離す単体テスト自動化の極意

業務自動化の道を歩む皆さん、こんにちは！
チーフアーキテクトの〇〇です。

「マクロの記録」から一歩踏み出し、Visual Basic (.NET)の世界でより堅牢で信頼性の高いシステムを構築したいと願う皆さんにとって、今日のテーマはまさに『飛躍』への鍵となるでしょう。

私たちが日々開発するシステムは、往々にしてデータベースや外部のWeb API、ファイルシステムといった「外部の存在」に依存しています。これらの外部依存があるがゆえに、私たちの書いたビジネスロジックの動作確認が難しくなり、品質保証の壁にぶつかることは少なくありません。

でも、安心してください。
今日は、その壁を乗り越え、CI/CD（継続的インテグレーション/継続的デリバリー）環境でもサクサクと実行できる自動テストコードをVB.NETで記述する「極限の知見」を、魂を込めてお伝えします。

本記事では、以下の強力なツールを使いこなす術を学んでいきます。

• NUnit / xUnit: VB.NETのコードをテストするためのフレームワーク
• Moq (モック): 外部依存を「偽物」に置き換え、純粋なビジネスロジックだけをテストするためのライブラリ

さあ、一緒にVisual Basic (.NET)を掌握し、あなたのコードに盤石な信頼性をもたらしましょう！

なぜテスト自動化が必要なのか？

「テストなんて、プログラムが動けばいいんじゃないの？」
「手動で確認すれば十分じゃないか？」

そう思われる方もいるかもしれません。しかし、ビジネスロジックが複雑化し、システムの規模が大きくなるにつれて、手動テストの限界はすぐにやってきます。

1. 時間とコストの増大: 全ての機能を網羅的に手動でテストするには膨大な時間がかかります。しかも、何か変更を加えるたびに、そのテストを繰り返さなければなりません。
2. 見落としとヒューマンエラー: 人間は完璧ではありません。手動テストでは、どうしてもテストケースの漏れや確認ミスが発生し、バグを見落とすリスクが高まります。
3. リファクタリングの恐怖: 「このコード、もっときれいにしたいけど、変な影響が出たらどうしよう…」自動テストがないと、コードの改善（リファクタリング）に大きな不安がつきまといます。
4. CI/CDとの連携: 現代の開発では、コードの変更が自動的にビルド、テスト、デプロイされるCI/CDパイプラインが不可欠です。自動テストは、このパイプラインの心臓部となります。

自動テストは、開発者の「安心」と「自信」を生み出し、長期的なシステムの品質と保守性を飛躍的に向上させる投資なのです。バグは友達、と言われますが、友達は少ない方がいいですよね。

単体テストとは何か？

単体テスト（Unit Test）とは、プログラムの最小単位（ユニット）が意図した通りに機能するかどうかを検証するテストです。

VB.NETの世界では、この「最小単位」とは、通常、特定のメソッドやプロパティ、あるいは一つのクラス全体を指します。

しかし、ここで大きな壁にぶつかります。
たとえば、以下のようなVB.NETのコードがあったとしましょう。

.net
Public Class UserService
Private _userRepository As IUserRepository ‘ データベースアクセスを担当するクラス

Public Sub New(userRepository As IUserRepository)
_userRepository = userRepository
End Sub

‘ ユーザーの合計ポイントを取得するビジネスロジック
Public Function GetTotalUserPoints(userId As Integer) As Integer
‘ ここでデータベースからユーザー情報を取得
Dim user = _userRepository.GetUserById(userId)

If user Is Nothing Then
Return 0
End If

‘ ポイント計算ロジック
Return user.LoginCount 10 + user.PurchaseAmount \ 100
End Function
End Class

‘ データベースアクセスを抽象化したインターフェース（後で詳しく説明します）
Public Interface IUserRepository
Function GetUserById(userId As Integer) As User
End Interface

Public Class User
Public Property Id As Integer
Public Property Name As String
Public Property LoginCount As Integer
Public Property PurchaseAmount As Integer
End Class

この `GetTotalUserPoints` メソッドをテストしたいのですが、このメソッドは `_userRepository` を介してデータベースにアクセスします。

• テスト実行のたびにデータベースに接続するのは遅いし、環境の準備も大変。
• データベースに特定のテストデータがないと、期待通りの結果を返せない。
• データベースエラーが発生したら、それは `GetTotalUserPoints` のバグなのか、データベースのバグなのか、切り分けが難しい。

このように、外部リソースに依存するメソッドをそのままテストしようとすると、テストは遅く、不安定になりがちです。

ここで登場するのが「モックオブジェクト」の魔法です！

モックオブジェクトの魔法：Moqの登場

モックオブジェクトとは、テスト対象のコードが依存する外部コンポーネント（データベース、API、ファイルなど）の「偽物」を作り出す技術です。

先ほどの例で言えば、`IUserRepository` という「データベースアクセス担当」の偽物を作って、`GetUserById` メソッドが呼ばれたら、実際にデータベースにアクセスする代わりに、「こんなユーザー情報が返ってきたよ」と予め設定したダミーデータを返すように仕向けるのです。

これにより、私たちは以下のメリットを享受できます。

• 高速性: 実際の外部リソースにアクセスしないため、テストが非常に高速になります。
• 独立性: 外部環境（ネットワークの状態、データベースのデータ内容）に左右されず、いつでも安定してテストを実行できます。
• 焦点: 純粋にビジネスロジック（この例では `GetTotalUserPoints` 内のポイント計算部分）だけをテストできます。

VB.NETでモックオブジェクトを簡単に作成するためのライブラリが「Moq」です。Moqは「モック（Mock）」という言葉から来ており、「モキュ」と読みます。

Moqのインストール方法

MoqはNuGetパッケージとして提供されています。Visual Studioから以下の手順でインストールできます。

1. テストプロジェクト（まだ作成していなければ、後述の手順で作成します）のソリューションエクスプローラーで「参照」または「依存関係」を右クリックし、「NuGetパッケージの管理」を選択します。
2. 「参照」タブで「Moq」と検索し、最新バージョンをインストールします。

コマンドラインからインストールする場合は、テストプロジェクトのフォルダで以下のコマンドを実行します。

dotnet add package Moq

これで、あなたのプロジェクトでMoqの魔法が使えるようになります。

テストフレームワークの選択：NUnitとxUnit

単体テストを記述し、実行するためには「テストフレームワーク」が必要です。VB.NETの世界では、主に以下の2つがよく使われます。

• NUnit: .NETの世界で最も歴史があり、広く使われているテストフレームワークの一つです。直感的で分かりやすい構文が特徴です。
• xUnit.net: NUnitよりも後発ですが、よりシンプルで拡張性の高い設計思想を持つフレームワークです。CI/CDとの相性も良いとされています。

どちらも優れたフレームワークですが、今回は初学者の方にも混乱なく理解していただくため、より伝統的で多くのドキュメントが存在するNUnitに焦点を当てて解説を進めます。基本的な考え方はxUnitでも共通ですので、NUnitを理解すればxUnitへの移行も容易です。

NUnitのインストール方法

Moqと同様に、NUnitもNuGetパッケージとして提供されています。

1. テストプロジェクトの「NuGetパッケージの管理」で「NUnit」と検索し、最新バージョンをインストールします。
2. さらに、テストエクスプローラーでテストを検出・実行するために「NUnit3TestAdapter」も検索してインストールしてください。

コマンドラインからインストールする場合は、テストプロジェクトのフォルダで以下のコマンドを実行します。

dotnet add package NUnit
dotnet add package NUnit3TestAdapter

これで、テストを記述し、実行するための準備が整いました。

実践！VB.NETでの単体テスト自動化

それでは、具体的なコード例を通して、単体テストとモックオブジェクトの活用法を学んでいきましょう。

シナリオ設定：ユーザーポイント計算サービスのテスト

先ほどの例を使い、ユーザーのログイン回数と購入金額に基づいて合計ポイントを計算する `UserService` の `GetTotalUserPoints` メソッドをテストします。

ステップ1: プロジェクトの準備

まず、ビジネスロジックを格納するプロジェクトと、それをテストするためのプロジェクトの2つを用意します。

1. ビジネスロジック用プロジェクトの作成:

• Visual Studioで新しいプロジェクトを作成します。
• テンプレートは「クラスライブラリ (.NET)」を選択し、プロジェクト名を `MyBusinessLogic` などとします。

2. テストプロジェクトの作成:

• 同じソリューションに新しいプロジェクトを追加します。
• テンプレートは「NUnit テストプロジェクト (.NET)」を選択し、プロジェクト名を `MyBusinessLogic.Tests` などとします。

3. 参照の追加:

• `MyBusinessLogic.Tests` プロジェクトから、`MyBusinessLogic` プロジェクトへの参照を追加します。
• `MyBusinessLogic.Tests` の「依存関係」または「参照」を右クリックし、「プロジェクト参照の追加」を選択。
• `MyBusinessLogic` プロジェクトにチェックを入れてOKします。
• `MyBusinessLogic.Tests` プロジェクトに、先ほど説明した NUnit と Moq のNuGetパッケージをインストールします。

ステップ2: インターフェースの定義とビジネスロジック

`MyBusinessLogic` プロジェクトに、以下のインターフェースとクラスを追加します。
インターフェースを定義することは、モックオブジェクトを作成し、依存性を注入（DI: Dependency Injection）するための重要なステップです。これにより、`UserService` は具体的なデータベース実装に依存せず、`IUserRepository` という「契約」にのみ依存するようになります。

.net
‘ MyBusinessLogic/IUserRepository.vb
Namespace MyBusinessLogic.Data
Public Interface IUserRepository
‘ 指定されたIDのユーザー情報を取得する
Function GetUserById(userId As Integer) As User
End Interface

‘ ユーザー情報を表すシンプルなクラス
Public Class User
Public Property Id As Integer
Public Property Name As String
Public Property LoginCount As Integer
Public Property PurchaseAmount As Integer
End Class
End Namespace

‘ MyBusinessLogic/UserService.vb
Namespace MyBusinessLogic.Services
Imports MyBusinessLogic.Data ‘ IUserRepository と User クラスを使うため

Public Class UserService
Private ReadOnly _userRepository As IUserRepository

‘ コンストラクタでIUserRepositoryのインスタンスを受け取る（依存性注入）
Public Sub New(userRepository As IUserRepository)
_userRepository = userRepository
End Sub

‘ ユーザーの合計ポイントを計算するビジネスロジック
‘ ログイン回数 10ポイント + 購入金額 / 100ポイント
Public Function GetTotalUserPoints(userId As Integer) As Integer
‘ 外部依存（データベースアクセス）はIUserRepositoryに任せる
Dim user = _userRepository.GetUserById(userId)

If user Is Nothing Then
Return 0 ‘ ユーザーが存在しない場合は0ポイント
End If

‘ 純粋なビジネスロジック（ここをテストしたい！）
Return user.LoginCount 10 + user.PurchaseAmount \ 100
End Function
End Class
End Namespace

ステップ3: モックを使ったテストコードの記述

次に、`MyBusinessLogic.Tests` プロジェクトに以下のテストコードを追加します。

.net
‘ MyBusinessLogic.Tests/UserServiceTests.vb
Imports NUnit.Framework ‘ NUnitの属性やアサーションを使うため
Imports Moq ‘ Moqライブラリを使うため
Imports MyBusinessLogic.Data ‘ IUserRepository, User クラスを使うため
Imports MyBusinessLogic.Services ‘ UserService クラスを使うため

‘ このクラスがテストクラスであることをNUnitに伝える属性

Public Class UserServiceTests

‘ Testメソッドが実行される前に毎回実行される初期化処理
Private _userRepositoryMock As Mock(Of IUserRepository)
Private _userService As UserService

Public Sub Setup()
‘ 各テストメソッドの前に新しいモックインスタンスを作成
_userRepositoryMock = New Mock(Of IUserRepository)()
‘ UserServiceにモックインスタンスを注入
_userService = New UserService(_userRepositoryMock.Object)
End Sub

‘ — 正常系のテストケース —

‘ ユーザーが存在し、ポイントが正しく計算される場合のテスト

Public Sub GetTotalUserPoints_ExistingUser_CalculatesCorrectPoints()
‘ Arrange (準備): テストに必要な条件を整える
‘ ID=1のユーザーがGetUserByIdで返されるようにモックを設定
Dim testUser = New User With {
.Id = 1,
.Name = “Test User”,
.LoginCount = 5, ‘ 5回ログイン
.PurchaseAmount = 1200 ‘ 1200円購入
}
‘ GetUserById(1)が呼ばれたら、上記のtestUserを返すように設定
‘ VB.NETではラムダ式でFunction(x) x.Method(args)のように記述します
_userRepositoryMock.Setup(Function(x) x.GetUserById(1)).Returns(testUser)

‘ Act (実行): テスト対象のメソッドを実行する
Dim actualPoints As Integer = _userService.GetTotalUserPoints(1)

‘ Assert (検証): 期待する結果が得られたか確認する
‘ 期待値: ログイン5回 10 + 購入1200円 / 100 = 50 + 12 = 62
Assert.AreEqual(62, actualPoints, “ユーザーが存在する場合、ポイントが正しく計算されるべきです。”)

‘ GetUserByIdが1回だけ呼ばれたことを検証
_userRepositoryMock.Verify(Function(x) x.GetUserById(1), Times.Once(), “GetUserByIdは1回だけ呼ばれるべきです。”)
End Sub

‘ — 異常系・境界値のテストケース —

‘ ユーザーが存在しない場合のテスト

Public Sub GetTotalUserPoints_NonExistingUser_ReturnsZero()
‘ Arrange (準備): ユーザーが存在しないという条件を設定
‘ GetUserByIdが呼ばれたら、Nothing（DBにユーザーがいない状態）を返すように設定
_userRepositoryMock.Setup(Function(x) x.GetUserById(It.IsAny(Of Integer))).Returns(Nothing)

‘ Act (実行): テスト対象のメソッドを実行する
Dim actualPoints As Integer = _userService.GetTotalUserPoints(999) ‘ 存在しないIDを仮定

‘ Assert (検証): 期待する結果が得られたか確認する
Assert.AreEqual(0, actualPoints, “ユーザーが存在しない場合、ポイントは0であるべきです。”)

‘ GetUserByIdが1回だけ呼ばれたことを検証
‘ It.IsAny(Of Integer) は、任意のInteger型の引数で呼ばれた場合にマッチします
_userRepositoryMock.Verify(Function(x) x.GetUserById(It.IsAny(Of Integer)), Times.Once(), “GetUserByIdは1回だけ呼ばれるべきです。”)
End Sub

‘ ログイン回数も購入金額も0の場合のテスト

Public Sub GetTotalUserPoints_ZeroLoginAndPurchase_ReturnsZero()
‘ Arrange (準備)
Dim testUser = New User With {
.Id = 2,
.Name = “Zero User”,
.LoginCount = 0,
.PurchaseAmount = 0
}
_userRepositoryMock.Setup(Function(x) x.GetUserById(2)).Returns(testUser)

‘ Act (実行)
Dim actualPoints As Integer = _userService.GetTotalUserPoints(2)

‘ Assert (検証)
Assert.AreEqual(0, actualPoints, “ログインも購入もないユーザーは0ポイントであるべきです。”)
End Sub

End Class

コードの意味とポイント

• `Imports NUnit.Framework`, `Imports Moq`, `Imports MyBusinessLogic.Data`, `Imports MyBusinessLogic.Services`: 必要なライブラリや名前空間をインポートします。
• `` 属性: このクラスがNUnitのテストをまとめたものであることを示します。
• `` メソッド: 各テストメソッドが実行される「前」に、共通の初期化処理を行うためのメソッドです。ここでモックとサービスを毎回新しく作成することで、テスト間の相互干渉を防ぎます。
• `New Mock(Of IUserRepository)()`: `IUserRepository` インターフェースのモックオブジェクトを作成します。
• `_userRepositoryMock.Object`: モックオブジェクト自体ではなく、モックされた `IUserRepository` のインスタンス (`_userRepositoryMock` が持っている `Object` プロパティ) を `UserService` のコンストラクタに渡します。これを「依存性注入（DI）」と言います。
• `` 属性: このメソッドがNUnitのテストメソッドであることを示します。
• `_userRepositoryMock.Setup(Function(x) x.GetUserById(1)).Returns(testUser)`: ここがMoqの肝です。
• `Setup(Function(x) x.GetUserById(1))`: `_userRepositoryMock` の `GetUserById` メソッドが引数 `1` で呼ばれたら…
• `.Returns(testUser)`: `testUser` オブジェクトを返す、という振る舞いを設定しています。
• VB.NETでは、ラムダ式は `Function(引数) 処理` の形式で記述します。C#の `x => x.GetUserById(1)` とは少し書き方が異なりますので注意しましょう。
• `It.IsAny(Of Integer)`: `GetUserById` メソッドが「どんなInteger型の引数」で呼ばれてもマッチするように設定する際に使います。これは汎用的なテストケースで非常に便利です。
• `Assert.AreEqual(期待値, 実際の結果, “メッセージ”)`: NUnitが提供する検証メソッドです。期待する値と実際の値が等しいかを比較します。もし異なればテストは失敗と判断されます。
• `_userRepositoryMock.Verify(Function(x) x.GetUserById(1), Times.Once(), “メッセージ”)`: モックオブジェクトの特定のメソッドが「呼び出されたか」「何回呼び出されたか」を検証することができます。これは、ビジネスロジックが正しく外部依存とインタラクションしているかを確認するために非常に重要です。

陥りやすいエラーとデバッグのヒント

• `NullReferenceException`: モックの `Setup` を忘れていたり、モックオブジェクトの `Object` プロパティを渡さずにモック自体を渡してしまったりすると発生します。
• `Public` 漏れ: テストクラスやテストメソッドは、NUnitが検出できるように必ず `Public` で宣言してください。
• `TestFixture` / `Test` 属性の忘れ: これがないとNUnitはテストクラスやテストメソッドを認識できません。
• テストエクスプローラーに表示されない: `NUnit3TestAdapter` のインストール忘れや、ビルドが正常に行われていない可能性があります。ソリューションをリビルドしてみてください。
• VB.NETのラムダ式: `Function(x) x.Method()` の書き方に慣れるまで少し時間がかかるかもしれません。IntelliSenseを頼りに、正しい構文で記述しましょう。

テストコードは、まるであなたのビジネスロジックの「取扱説明書」のようなものです。誰が読んでも、その機能が何をすべきかを理解できるような、明確で分かりやすいテストを心がけましょう。

CI/CD環境でのテスト自動化

ここまでで、VB.NETとNUnit、Moqを使って、外部依存から切り離された単体テストを記述する方法を学びました。この単体テストは、CI/CDパイプラインにおいて非常に重要な役割を果たします。

1. 自動実行: コードがコミットされるたび、または特定のタイミングで、自動的に全ての単体テストが実行されます。
2. 早期フィードバック: テストが失敗すれば、すぐに開発者に通知されます。これにより、問題が大きくなる前に修正することができます。
3. 品質ゲート: 全てのテストに合格しない限り、次のステップ（結合テスト、ステージング環境へのデプロイなど）に進めないように設定できます。これにより、常に高品質なコードが保たれます。

単体テストの自動化は、単なるバグ発見ツールではありません。それは、開発プロセス全体の効率と信頼性を高め、ビジネス価値を迅速に提供するための、戦略的な基盤なのです。

まとめと次のステップ

皆さん、お疲れ様でした！

今日は、Visual Basic (.NET)の世界で、NUnit/xUnitとMoqを活用して外部依存を切り離し、堅牢なビジネスロジックを担保するための単体テスト自動化の極意を学びました。

• なぜテスト自動化が必要なのか、その本質的な価値を理解しました。
• モックオブジェクト（Moq）が、いかに外部依存の壁を乗り越える強力なツールであるかを知りました。
• NUnitを使って、VB.NETで実際のテストコードを記述し、その構造と意味を深く掘り下げました。

ここをクリアすれば、Visual Basic (.NET)を使った開発における品質保証の基本はバッチリですよ！

この知識を土台として、さらに以下のステップに進むことをお勧めします。

• テスト駆動開発 (TDD): テストを先に書き、それからコードを実装するという開発手法です。設計品質の向上にもつながります。
• より複雑なモックの活用: 非同期メソッドのモック、イベントの発火、複数の引数に対する異なる戻り値の設定など、Moqにはさらに多くの機能があります。
• 統合テスト: 単体テストだけでなく、複数のコンポーネントが連携して動作するかを確認する統合テストにも挑戦してみましょう。
• CI/CDパイプラインへの組み込み: 実際にAzure DevOpsやGitHub ActionsなどのCI/CDサービスにあなたのテストを組み込んでみましょう。

あなたのVB.NETでの開発が、より楽しく、より確実なものになることを心から願っています。
それでは、また次の記事でお会いしましょう！