枯れた技術を、極限まで研ぎ澄ます。FlaUIによるWindows Forms自動化の真髄
「Windows Formsはレガシーである」。そう吐き捨ててモダンなWeb開発へ逃げるのは簡単だ。しかし、現場の泥臭い業務を支え続けてきたあの巨大なフォーム群こそが、真の資産であり、同時に最大のボトルネックであることも知っているはずだ。
GUIの自動テストは、往々にして「壊れやすい（Brittle）」という十字架を背負う。特に、開発者が意図しないコントロールの階層構造や、非同期処理の絡み合いは、自動化スクリプトを単なる「ゴミ」に変えてしまう。
今日は、FlaUIを用いてWindows FormsのUIテストをCI/CDパイプラインに組み込み、リグレッションを無力化するための「極限の知見」を共有しよう。
—
1. UIオートメーションの「魂」：UIA3の選択と回避策
Windows Formsのテストにおいて、UI Automation (UIA) のバージョン選択は死活問題だ。UIA2は枯れているが、WPFとの混在環境や最新のWindows OSではUIA3が必須となる。
FlaUIを使用する際、最も重要なのは「AutomationType」の明示的な指定だ。
‘ FlaUIによる初期化：UIA3を選択し、WinFormsの深い階層を探索する
Dim app As Application = Application.Launch(“C:\Path\To\YourApp.exe”)
Using automation As New UIA3Automation()
‘ Windowを取得し、フォーカスを強制する
Dim window As Window = app.GetMainWindow(automation)
window.Focus()
‘ ここで重要なのは、タイムアウト設定だ。CI環境ではマシンスペックが
‘ 低いため、デフォルトの短すぎる待機時間はリグレッションの原因となる。
automation.ConnectionSettings.WaitTimeout = TimeSpan.FromSeconds(10)
End Using
—
2. メモリ管理とオブジェクトライフサイクル：IDisposableの徹底
VB.NETのガベージコレクタ（GC）を信じてはいけない。UIオートメーションの要素（AutomationElement）は、背後でWin32 APIのハンドルを掴んでいる場合がある。特にCI/CD上で並列テストを回す場合、オブジェクトの解放漏れはメモリリークを招き、ランナー自体をクラッシュさせる。
極意：`Using`句を溺愛せよ。
‘ 要素取得はスコープを限定する
Using automation As New UIA3Automation()
Dim mainWindow As Window = app.GetMainWindow(automation)
‘ Button要素を検索し、操作後に即時解放を促す構成にする
Dim submitButton As Button = mainWindow.FindFirstDescendant(Function(cf) cf.ByAutomationId(“btnSubmit”)).AsButton()
If submitButton IsNot Nothing Then
submitButton.Click()
End If
‘ Usingを抜けることで、アンマネージドリソースの解放が確約される
End Using
—
3. レガシーUIを掌握する「Find」の哲学
WinFormsの複雑なGridコントロール（DataGridViewなど）は、オートメーションの天敵だ。`FindFirstDescendant`で全探索を繰り返すと、テスト実行時間は指数関数的に増大する。
シニアエンジニアの最適化テクニック：
1. AutomationIdの強制: レガシーアプリのコードに手が入るなら、主要なコントロールには必ず `AccessibleName` や `AutomationId` を振れ。それができない場合は、コントロールの「名前」と「クラス名」を組み合わせた独自の検索ラッパーを書くこと。
2. 待機戦略の適正化: `Thread.Sleep` は悪だ。`Retry.While` を用いたイベント駆動型の待機を実装せよ。
‘ FlaUIのRetry.Whileを使用した、非同期処理を待つ賢いテスト手法
Retry.WhileFalse(Function()
Return mainWindow.FindFirstDescendant(Function(cf) cf.ByAutomationId(“lblStatus”)).AsLabel().Text = “Complete”
End Function, TimeSpan.FromSeconds(30))
—
4. CI/CDパイプライン連携の極意：ヘッドレス環境の壁
Windows FormsのUIテストをAzure DevOpsやGitHub Actionsで実行する際、最大の壁は「対話型セッションの欠如」だ。GUIはスクリーンがない環境では描画されない。
- 解決策: Windowsの「Interactive Services Detection」は過去のものだ。現在は、テストランナーを「Interactive」なサービスアカウントで実行するか、あるいは `xvfb` 的な仮想ディスプレイを構築する手法もあるが、最も現実的なのは「物理的なビルドエージェントを一台、専用のテストランナーとして用意すること」である。
CI環境で実行する際は、必ず以下の引数をアプリケーションに渡す設計にしておけ。
‘ テスト実行時のみ有効なフラグを渡す（例： –automation-mode）
Dim startInfo As New ProcessStartInfo(“MyApp.exe”, “–automation-mode”)
‘ UIの状態を確定させるために、環境変数でロケールやスタイルを固定する
startInfo.EnvironmentVariables(“UI_TEST_MODE”) = “1”
—
最後に：エンジニアとしての矜持
「自動化」は、一度書いて終わりではない。UIが変わればテストも変わる。しかし、このテストコードが存在すること自体が、開発者に「安易にUI設計を変えてはならない」という強烈な規律を課すことになる。
VB.NETという枯れた言語を使いながら、最先端のCI/CDパイプラインを回す。これこそが、レガシーシステムを「負債」から「資産」へと変える唯一の道だ。
コードを書き殴るな。アーキテクチャを設計しろ。そして、テストが通った瞬間の静寂を愛せ。それが、プロフェッショナルの仕事だ。
