「Button_Click」にロジックを閉じ込めるな。VB.NET WinFormsにおける、テスト可能な堅牢なアーキテクチャへの転換
「動けばいい」――そんな甘い考えで書かれたWindows Forms（WinForms）アプリケーションが、数ヶ月後の保守フェーズでどれほどの悲鳴を上げることになるか、君は想像したことがあるだろうか。
ボタンのクリックイベントに、データベースへの接続、ファイル操作、そして複雑な計算ロジックをすべて書き連ねる。いわゆる「スパゲッティ・コード」の典型だ。これでは、ロジックがUI（画面）という強固な殻に閉じ込められ、自動テストを試みることすら不可能になる。UIが立ち上がらなければテストできないコードは、もはや「検証可能なソフトウェア」とは呼べないのだ。
今日は、業務効率化ツールの開発において、バグを未然に防ぎ、変更に強い、真に「プロフェッショナル」なVB.NETアプリケーションを構築するための設計思想と、NUnitおよびMoqを用いた自動テストの導入手法を伝授する。
1. なぜ、君のコードはテストできないのか？
WinForms開発者が陥る最大の罠は、「UIとロジックの密結合」だ。
`Form1.vb` の中に `If…Then` や `Try…Catch` が溢れかえっていないか？ もしそうなら、そのロジックをテストするには、実際にウィンドウを表示し、ボタンを擬似的にクリックし、テキストボックスの値を操作しなければならない。これは「ユニットテスト」ではない。UIテスト（結合テスト）であり、実行速度が遅く、不安定で、メンテナンスコストが極めて高い。
我々が目指すべきは、「UI（表示）」「Presenter（制御）」「Model（データ・ロジック）」を完全に分離したアーキテクチャ、すなわち MVP (Model-View-Presenter) パターンである。
2. アーキテクチャの設計図：MVPパターンの適用
ロジックをテスト可能にするための鍵は、「インターフェース（Interface）」による抽象化だ。
- View (Form): ユーザーの入力を受け取り、結果を表示するだけの「薄い」存在。ロジックは一切持たない。
- Presenter: ViewとModelの仲介役。Viewからイベントを受け取り、Modelを呼び出し、その結果をViewに反映させる。ここがテストの主戦場だ。
- Model (Service/Repository): データベース操作やファイルI/O、純粋なビジネスロジックを担う。
実装例：ユーザー登録機能
まず、ViewとRepositoryをインターフェースとして定義する。これが「依存性の注入（DI）」の準備となる。
' --- Interface層 ---
''' <summary>
''' View（画面）の振る舞いを定義するインターフェース
''' </summary>
Public Interface IUserView
Property UserName As String
Property StatusMessage As String
Sub ShowError(message As String)
End Interface
''' <summary>
''' データアクセス層のインターフェース
''' </summary>
Public Interface IUserRepository
Function SaveUser(name As String) As Boolean
End Interface次に、このインターフェースを利用する Presenter を実装する。Presenterは、具体的な `Form` クラスではなく、`IUserView` を知っているだけだ。
' --- Presenter層 ---
Public Class UserPresenter
Private ReadOnly _view As IUserView
Private ReadOnly _repository As IUserRepository
''' <summary>
''' コンストラクタで依存関係を注入する（Dependency Injection）
''' </summary>
Public Sub New(view As IUserView, repository As IUserRepository)
_view = view
_repository = repository
End Sub
''' <summary>
''' 登録ボタンが押された時のロジック
''' </summary>
Public Sub RegisterUser()
' 1. バリデーション（ビジネスロジック）
If String.IsNullOrWhiteSpace(_view.UserName) Then
_view.ShowError("ユーザー名は必須です。")
Return
End If
' 2. モデルへの保存実行
Try
Dim success As Boolean = _repository.SaveUser(_view.UserName)
If success Then
_view.StatusMessage = $"ユーザー {_view.UserName} を登録しました。"
Else
_view.ShowError("保存に失敗しました。")
End If
Catch ex As Exception
_view.ShowError($"予期せぬエラーが発生しました: {ex.Message}")
End Try
End Sub
End Class3. NUnitとMoqによる「極限のテスト」
さて、ここからが本番だ。Presenterが完成した。このPresenterが「空の名前が渡されたときに正しくエラーを表示するか」「保存に成功したときにメッセージを更新するか」を、画面を一切出さずにテストする。
ここで、Moq（モックライブラリ）の出番だ。Moqを使えば、`IUserView` や `IUserRepository` の「偽物（Mock）」を瞬時に生成できる。
テストコードの実装
NUnitプロジェクトを作成し、以下のテストを記述する。
Imports NUnit.Framework
Imports Moq
<TestFixture>
Public Class UserPresenterTests
Private _mockView As Mock(Of IUserView)
Private _mockRepository As Mock(Of IUserRepository)
Private _presenter As UserPresenter
<SetUp>
Public Sub Setup()
' 各テストの前に、モックオブジェクトを初期化する
_mockView = New Mock(Of IUserView)()
_mockRepository = New Mock(Of IUserRepository)()
' Presenterにモックを注入
_presenter = New UserPresenter(_mockView.Object, _mockRepository.Object)
End Sub
<Test>
<Description("ユーザー名が空の場合、エラーメッセージが表示されること")>
Public Sub RegisterUser_EmptyUserName_ShowsError()
' Arrange: ユーザー名を空に設定
_mockView.Setup(Function(v) v.UserName).Returns("")
' Act: 登録処理を実行
_presenter.RegisterUser()
' Assert: ShowErrorメソッドが1回呼ばれたことを検証
_mockView.Verify(Function(v) v.ShowError(It.IsAny(Of String)()), Times.Once)
' 保存処理は呼ばれていないことを確認
_mockRepository.Verify(Function(r) r.SaveUser(It.IsAny(Of String)()), Times.Never)
End Sub
<Test>
<Description("保存に成功した場合、ステータスメッセージが更新されること")>
Public Sub RegisterUser_Success_UpdatesStatusMessage()
' Arrange: ユーザー名を設定し、RepositoryがTrueを返すように設定
_mockView.Setup(Function(v) v.UserName).Returns("Taro")
_mockRepository.Setup(Function(r) r.SaveUser("Taro")).Returns(True)
' Act
_presenter.RegisterUser()
' Assert: ステータスメッセージが期待通りであることを検証
_mockView.VerifySet(Function(v) v.StatusMessage = "ユーザー Taro を登録しました。")
End Sub
End Classなぜこれが「最強」なのか？
1. 高速: 数百個のテストを実行しても、数秒で終わる。
2. 決定論的: DBやファイルシステムに依存しないため、「環境によってテストが落ちる」という悪夢が起きない。
3. 境界条件の網羅: 「DB接続が切れた時（Exceptionが発生した時）」のような、実際のUI操作では再現しにくいケースも、`_mockRepository.Setup(…).Throws(New Exception())` と書くだけで簡単にテストできる。
4. 実務における注意点：ファイル・DB連携の罠
業務ツールにおいて、ファイル操作やDBアクセスは避けて通れない。しかし、これらを直接 Presenter や Form に書くことは「設計の死」を意味する。
- File I/O: `System.IO.File.WriteAllText` を直接呼ぶのではなく、`IFileService` インターフェースを介せ。テスト時にはメモリ上の文字列として扱うモックに差し替えることで、テスト実行中に不要なファイルが生成されるのを防げる。
- Database: SQL文を直接書くのではなく、`IRepository` に隠蔽せよ。ユニットテストでは、本物のSQLを実行するのではなく、「Repositoryが値を返したと仮定する」ことで、ロジックの検証に集中するのだ。
5. CI/CDパイプラインへの統合
せっかく書いたテストも、開発者が実行し忘れたら意味がない。
現代的な開発では、GitHub Actions や Azure DevOps を用いて、コードをPushするたびに自動的にテストを実行する仕組みを構築すべきだ。
`.github/workflows/dotnet.yml` 等の設定ファイルに、以下のコマンドを含めるだけでいい。
- name: Test
run: dotnet test --configuration Releaseこれにより、「テストが通らないコードは、メインブランチにマージできない」という鉄の掟を自動的に適用できる。これが、バグのない堅牢なシステムを維持する唯一の道だ。
結論：エンジニアとしての矜持
「動くコード」を書くのは、初級者だ。
「テスト可能で、変更に強く、保守しやすいコード」を書くのが、プロフェッショナルだ。
WinFormsは古い技術だと言われることもある。しかし、アーキテクチャの原則は時代に左右されない。インターフェースによる抽象化、依存性の注入、そして自動テスト。これらをマスターすることで、君が作る業務ツールは、単なる「便利ツール」から、企業の基幹を支える「信頼に足るシステム」へと昇華するだろう。
さあ、今すぐその `Button_Click` の中身を、インターフェースの向こう側へ解き放て。
