Windows Formsの呪縛を断ち切れ：FlaUIで実現する極限のUIテスト自動化アーキテクチャ
こんにちは。チーフアーキテクトの私だ。
皆さんの現場には、まだ「門外不出の神 Excel」や、保守担当者が変わるたびに冷や汗を流すレガシーなWindows Forms（WinForms）アプリケーションが鎮座していないだろうか？
「画面の仕様変更のたびに、手動で全画面のポチポチテストを強いられている」
「デプロイ前のリグレッションテストだけでエンジニアの工数が溶けていく」
もし心当たりがあるなら、今すぐその非効率な泥沼から抜け出すべきだ。UIテストは人間の手で行うものではない。マシンにやらせるのだ。今回は、`.NETの世界においてレガシーWinFormsアプリを完全無欠に自動テストする手法`を、FlaUIという最強のオープンソースフレームワークを用いて伝授する。
中途半端なマウスクリックのシミュレーションや、不安定な座標依存のスクリプトとは今日で決別しよう。UIオートメーションの深層を理解したプロの設計を、コードとともに叩き込む。
—
なぜ「素のUIAutomation」では破綻するのか？
WinFormsのテスト自動化と聞くと、.NET標準の `System.Windows.Automation` を直接叩くコードを書く者がいる。だが、それを本番運用しようものなら、必ず地獄を見る。
1. タイミング同期の欠如: アプリの起動やデータベースからの非同期データロード完了を待てず、テストが「要素が見つからない」という理由で気まぐれに落ちる（いわゆるFlaky Testsの量産）。
2. コントロール識別子の迷子: WinForms特有の動的生成されるコントロール名や、階層構造の複雑さに耐えきれず、UIのわずかなレイアウト変更でテストが全滅する。
3. 例外ハンドリングの欠如: テストランナーが予期せぬダイアログ（「未保存の変更があります」など）に阻まれた際、プロセスがデッドロックする。
ここで登場するのが FlaUI だ。UIA2およびUIA3（UI Automation API）をラップし、モダンで直感的なC#/VB.NETのAPIを提供してくれる。これを使えば、WinFormsの泥臭いイベント駆動の裏側を綺麗に調停し、鉄壁の自動化スクリプトを構築できる。
—
堅牢なUIテスト自動化の全体設計
プロダクションコードに入る前に、アーキテクチャの原則を確認する。
- プロセスライフサイクルの厳格な管理: テストの前後（SetUp / TearDown）でターゲットアプリの起動・終了を確実に行い、ゾンビプロセスを残さない。
- リトライ機構とタイムアウトの明示化: 「要素が出現するまで最大5秒待つ」といった堅牢なポーリング処理を組み込む。
- ロジックとUI操作の分離: 画面のどこをクリックするかという「座標・セレクタ依存のコード」をテストシナリオから隔離する。
—
実装：FlaUIを用いたWinForms自動テストスクリプト
それでは、VB.NET（またはC#からの移行を見据えたモダンなVB.NET構文）による実用的なプロダクションコードを提示する。
ここでは、「顧客検索画面で検索キーワードを入力し、結果グリッドに値が表示されること、および確認ダイアログが正しく処理されること」を検証するシナリオを想定する。
1. 依存関係の導入 (NuGet)
プロジェクトに対し、以下のNuGetパッケージを導入しておくこと。
- `FlaUI.UIA3` (または `FlaUI.UIA2` – WinFormsならUIA3が推奨されるケースが多い)
2. テスト自動化クラスの実装 (VB.NET)
Imports System
Imports System.IO
Imports Microsoft.VisualStudio.TestTools.UnitTesting ‘ または NUnit / xUnit
Imports FlaUI.Core
Imports FlaUI.Core.AutomationElements
Imports FlaUI.UIA3
Public Class WinFormsAutomationTests
Private _app As Application
Private _automation As UIA3Automation
Private _mainWindow As Window
‘ テスト対象アプリのパス（環境に合わせて変更）
Private ReadOnly AppPath As String = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, “LegacyApp.exe”)
Public Sub Initialize()
‘ 【重要】プロセスライフサイクルの管理
‘ アプリをクリーンな状態から起動する
_automation = New UIA3Automation()
_app = Application.Launch(AppPath)
‘ メインウィンドウがアタッチされるまで最大10秒待機（タイムアウト対策）
_mainWindow = _app.GetMainWindow(_automation, TimeSpan.FromSeconds(10))
If _mainWindow Is Nothing Then
Throw New InvalidOperationException(“ターゲットアプリケーションのメインウィンドウを取得できませんでした。”)
End If
End Sub
Public Sub Cleanup()
‘ 【重要】リソースの確実な解放とゾンビプロセスの防止
If _mainWindow Is not Nothing Then
_mainWindow.Dispose()
End If
If _app IsNot Nothing Then
_app.Close()
_app.Dispose()
End If
If _automation IsNot Nothing Then
_automation.Dispose()
End If
End Sub
Public Sub Test_CustomerSearch_And_GridValidation()
‘ 1. テキストボックスの特定と入力
‘ AutomationId または Name プロパティで要素を確実に捉える
Dim searchTextBox As TextBox = _mainWindow.FindFirstDescendant(Function(cf) cf.ByAutomationId(“txtSearchKeyword”)).AsTextBox()
Assert.IsNotNull(searchTextBox, “検索テキストボックスが見つかりません。”)
‘ フォーカスを当てて安全に入力
searchTextBox.Focus()
searchTextBox.Text = “株式会社 業務自動化”
‘ 2. 検索ボタンのクリック
Dim searchButton As Button = _mainWindow.FindFirstDescendant(Function(cf) cf.ByAutomationId(“btnExecuteSearch”)).AsButton()
Assert.IsNotNull(searchButton, “検索ボタンが見つかりません。”)
searchButton.Click()
‘ 3. 非同期処理の完了待ち（データグリッドのロード）
‘ グリッドにデータ行がバインドされるまでポーリングで待機
Dim resultsGrid As DataGrid = _mainWindow.FindFirstDescendant(Function(cf) cf.ByAutomationId(“gridResults”)).AsDataGrid()
Assert.IsNotNull(resultsGrid, “結果グリッドが見つかりません。”)
‘ FlaUIのWait条件を利用して、行数が0より大きくなるのを最大5秒待つ
Dim hasRows = Retry.WhileFalse(
Function() resultsGrid.Rows.Length > 0,
TimeSpan.FromSeconds(5),
TimeSpan.FromMilliseconds(500)
)
Assert.IsTrue(hasRows, “タイムアウト: 検索結果がグリッドにロードされませんでした。”)
‘ 4. 結果の検証
Dim firstRowText As String = resultsGrid.Rows(0).Cells(1).Value
StringAssert.Contains(firstRowText, “株式会社 業務自動化”)
‘ 5. アクション後のダイアログ処理（確認メッセージボックスの自動閉塞）
Dim closeButton As Button = _mainWindow.FindFirstDescendant(Function(cf) cf.ByAutomationId(“btnClose”)).AsButton()
closeButton.Click()
‘ モーダルダイアログ（確認画面）が出現した場合のハンドリング
Dim modalDialog = _mainWindow.ModalWindow
If modalDialog IsNot Nothing Then
Dim yesButton = modalDialog.FindFirstDescendant(Function(cf) cf.ByText(“はい”)).AsButton()
If yesButton IsNot Nothing Then
yesButton.Click()
End If
End If
End Sub
End Class
—
アーキテクトが教える：実運用で絶対に押さえるべき「3つの鉄則」
上記のコードを見て、「動くからこれでよし」とするのはまだ早い。実務の現場、特にCI/CDパイプライン（GitHub ActionsやAzure DevOpsなど）に組み込む場合、以下の壁に必ずぶ当たる。
1. AutomationId を開発者に強制せよ
UI要素を特定する際、ボタンの「テキスト（Caption）」や「座標」に依存してはならない。画面の文言が「検索」から「データ検索」に変更されただけでテストが崩壊する。
WinForms側で、すべての主要なコントロールに対して `AccessibilityObject.Name` や `AutomationId` （VB.NETコード内なら `Control.AccessibleName` や `Name` プロパティ）に一意のIDを付与するコーディング規約をチーム全体に徹底させろ。これが自動化の成否を分ける。
2. CI環境（ヘッドレス／仮想デスクトップ）の罠
WinFormsアプリケーションのUIテストは、「実際のWindowsデスクトップセッション」を必要とする。Linuxベースの一般的なコンテナ環境では動かない。
ビルドサーバー（ agentes ）で実行する際は、必ずインタラクティブなWindowsセッション（セッション0分離の壁を越える設定、あるいは画面描画を伴うRDP/VNC環境や Windows Server のエージェント設定）を構築する必要がある。ここを怠ると、「ローカルでは動くのにCIサーバーで例外が起きる」という悪夢を見る。
3. データベース連携・ファイル連携テストのクリーンアップ
UIテストの実行によって、テスト対象アプリがバックエンドのデータベースにゴミデータを書き込んだり、ローカルのINIファイルや設定ファイルを汚染したりする場合がある。
テストの前処理（SetUp）または後処理（Cleanup）において、必ずSQLのトランザクションロールバックや、テスト用DBのバックアップからの復元、設定ファイルのモック化を自動化スクリプトのライフサイクルに組み込むこと。テストデータが原因で2回目以降のテストが失敗する事態は、プロとして絶対に避けるべきだ。
—
結びにかえて：レガシーの近代化はここから始まる
レガシーなWinFormsアプリケーションを抱えているからといって、手動テストという前時代的なコストを払い続ける言い訳にはならない。
FlaUIを導入し、プロセスとタイミングを完全に掌握した自動化スクリプトを構築すれば、どんなに古びた業務アプリであっても、モダンなWebアプリケーション並みのCI/CDリグレッション体制を手に入れることができる。
設計の要諦はいつの時代も変わらない。
「不確実性（タイミング、環境、データ）を排除し、コードですべてを決定論的に制御する」ことだ。
さあ、明日からの開発現場で、無駄な手動テストの撲滅を主導してくれたまえ。君の健闘を祈る。
