【生成AI活用】InputMan for Windows FormsのE2Eテストを試してみた（TestStack.White + Claude Code）

Posted at 2026-01-25

注意事項・免責事項

本記事について

本記事は個人的な検証プロジェクトの成果をまとめたものです。実際の業務システムではなく、学習・検証目的で作成したサンプルアプリケーションを対象としています。
試用版ライブラリを使用しています。InputMan for Windows Forms 12.0Jの試用版を使用してテストを実施しました。
商用利用する場合は正式なライセンスが必要です。メシウス社の製品を実際のプロジェクトで使用する場合は、必ず正式なライセンスを取得してください。
本記事はメシウス社の公式見解ではありません。記載内容は筆者個人の見解であり、メシウス社の公式なサポートや推奨を示すものではありません。

メシウス社について

本記事で使用している InputMan for Windows Forms は、メシウス株式会社（旧グレープシティ）が開発・販売する.NET Frameworkコンポーネント製品です。

公式サイト: MESCIUS InputMan for Windows Forms
デモアプリ: デモアプリケーション

正確な製品情報や技術サポートについては、上記の公式リソースをご参照ください。

背景と課題

既存のWindows FormsアプリケーションのE2Eテスト自動化において、以下の課題、制約がありました：

要素が見つからない問題: AutomationIdだけでは要素を特定できず、テストが何度も失敗する
要素取得の実行時間: 全コントロールを検索する段階的な検索処理は時間がかかり、実用的ではない場合がある
試用版ダイアログの自動処理: アプリ起動時に表示されるダイアログがテストをブロックし、自動化が困難
ウィンドウ位置の問題: ウィンドウが画面外に配置され、クリック操作が失敗する
デバッグ時間の増加: 失敗原因の特定に時間がかかり、テスト作成効率が低下
テストコード作成の知識不足: E2Eテストの実装経験が少なく、ベストプラクティスが分からない

本記事では、生成AI（Claude Code）を活用しながら、これらの課題に対処し、MESCIUS InputMan for Windows Forms 12.0JのE2Eテストを構築した過程と解決策を共有します。

AI活用のポイント: テストコードの生成だけでなく、「要素が見つからない」問題に対する3段階の段階的検索（複数の方法を順番に試す仕組み）の設計、エラーハンドリングの実装、デバッグ方法の提案まで、AIとの対話を通じて最適な実装を導き出しました。

注: 本記事ではClaude Codeを使用しましたが、GitHub Copilotでも同様のアプローチが可能です。AIツールの選択は開発環境や好みに応じて選択してください。

環境

テスト対象・フレームワーク

対象アプリ: InputMan for Windows Forms 12.0J デモアプリケーション
テストフレームワーク: MSTest 4.0.1
UI自動化ライブラリ: TestStack.White 0.13.3
.NET: .NET Framework 4.8
言語: VB.NET

開発環境

OS: Windows 10/11
開発ツール: Visual Studio 2022 community または .NET CLI
生成AI: Claude Code（GitHub Copilot、その他のAIコーディング支援ツールでも同様のアプローチが可能）

生成AIへのプロンプト例

実際にAIをどのように活用したか、具体的なプロンプト例を紹介します。

初期テストコード生成

InputMan for Windows FormsアプリケーションのE2Eテストを作成したい。
- 「書式による入力制限」→「テキストコントロール」ページに遷移
- テキストボックス(AutomationId: gcTextBox1)に「2212」を入力
- スクリーンショットを撮影
- 詳細なログを出力

プロジェクトファイルとテストコードを生成してください。

要素が見つからない問題への対処

テストで「要素が見つかりません」エラーが発生します。
Designer.vbを見ると、gcTextBox1のLocationは(8, 29)です。

AutomationIdで見つからない場合の段階的検索を実装してください：
1. AutomationIdで検索（最優先）
2. 座標範囲で推測（代替手段）
3. デバッグ用に全コントロールダンプ

各段階で詳細なログを出力し、どの方法で見つかったか分かるようにしてください。

エラーハンドリングとデバッグ機能

テストのロバスト性を向上させたい：
1. 各ステップで詳細なログを出力
2. エラー時にスクリーンショットを自動撮影
3. 操作前後にもスクリーンショットを撮影
4. try-catchで適切なエラーハンドリング

VB.NETで実装してください。

ポイント

具体的な技術スタックを明示: ライブラリ、バージョン、言語を指定
問題の詳細を共有: エラーメッセージ、ソースコード情報（Designer.vb）を提供
期待する動作を明確に: 段階的な検索戦略、ログ出力の要件を具体化
段階的に改善: 初回は基本実装、問題発生時に追加要件を指示

このように具体的で明確なプロンプトを使うことで、AIが適切なコードを生成しやすくなります。

導入手順

ここでは、E2Eテストプロジェクトを実際に動かすための手順を説明します。

前提条件

以下の環境が必要です：

OS: Windows 10/11
.NET Framework 4.8: インストール済みであること
開発ツール: 以下のいずれか
- Visual Studio 2022 Community（または.NET CLI）
- ※ただし、ビルド済みexeファイルがあればVisual Studioは不要です

ステップ1: InputManデモアプリケーションの入手

公式サイトからInputManデモアプリケーションをダウンロードします：

ダウンロードURL: InputMan デモアプリ
ダウンロード後、インストールまたは展開してexeファイルを取得
exeファイルのパスを控えておく（例: C:\Demo\InputMan.exe）

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

プロジェクトファイルの作成

以下の内容でE2ETests.vbprojを作成します：

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="MSTest" Version="4.0.1" />
    <PackageReference Include="TestStack.White" Version="0.13.3" />
  </ItemGroup>

  <ItemGroup>
    <Reference Include="System.Drawing" />
    <Reference Include="System.Windows.Forms" />
    <Reference Include="WindowsBase" />
    <Reference Include="UIAutomationTypes" />
    <Reference Include="UIAutomationClient" />
  </ItemGroup>
</Project>

パッケージのインストール

コマンドラインで以下を実行：

cd E2ETests
dotnet restore

これで、TestStack.White 0.13.3とMSTest 4.0.1が自動的にインストールされます。

ステップ3: 簡単なテストコードの作成

以下の内容でTextBoxControlTest.vbを作成します：

Imports Microsoft.VisualStudio.TestTools.UnitTesting
Imports TestStack.White
Imports TestStack.White.UIItems
Imports TestStack.White.UIItems.Finders
Imports TestStack.White.UIItems.WindowItems

<TestClass>
Public Class TextBoxControlTest
    Private app As Application
    Private mainWindow As Window

    <TestInitialize>
    Public Sub Setup()
        ' InputManアプリのパスを指定
        Dim appPath = "C:\Demo\InputMan.exe" ' ← 実際のパスに変更
        app = Application.Launch(appPath)
        mainWindow = app.GetWindow("メインウィンドウ名") ' ← 実際のウィンドウ名に変更
    End Sub

    <TestMethod>
    Public Sub TestTextBoxInput()
        Console.WriteLine("===== テスト開始 =====")

        ' ここにテストコードを追加

        Console.WriteLine("===== テスト成功 =====")
    End Sub

    <TestCleanup>
    Public Sub TearDown()
        If app IsNot Nothing Then
            app.Close()
        End If
    End Sub
End Class

ステップ4: テストの実行

dotnet test --logger "console;verbosity=detailed"

ステップ5: 生成AIでテストコードを充実させる

初期セットアップが完了したら、前述の「生成AIへのプロンプト例」を使って、テストコードを生成AIに作成してもらいます。

例えば：

InputMan for Windows FormsアプリケーションのE2Eテストを作成したい。
- 「書式による入力制限」→「テキストコントロール」ページに遷移
- テキストボックス(AutomationId: gcTextBox1)に「2212」を入力
- スクリーンショットを撮影
- 詳細なログを出力

プロジェクトファイルとテストコードを生成してください。

このプロンプトをClaude CodeやGitHub Copilotに投げることで、完全なテストコードを生成できます。

実際に試したときの画像

トラブルシューティング

Q: 要素が見つからないエラーが出る
→ Designer.vbから座標情報を取得して、3段階の段階的検索を実装してください（詳細は後述の「問題1: 要素が見つからない」セクションを参照）

Q: ダイアログが表示されてテストが止まる
→ 試用版の場合は公式サイトからビルド済みexeをダウンロードしてください（詳細は後述の「問題2: 試用版ダイアログが出現」セクションを参照）

Q: ウィンドウが見つからない
→ ウィンドウ位置の自動調整コードを追加してください（詳細は後述の「問題3: ウィンドウが画面外にある」セクションを参照）

なぜTestStack.Whiteなのか？

結論から言うと、**対象OSがWindows7を想定しているためです。**です。

TestStack.Whiteの特徴

✅ .NET Framework専用で安定動作
✅ Windows Formsに対応
✅ 枯れた技術で情報が豊富

注意: .NET移行時は別フレームワークへ

ただし、将来的に.NET 6/7/8以降に移行する場合は、TestStack.Whiteはおすすめしません。以下の代替フレームワークへの移行が必要です：

Appium WinAppDriver (推奨)
FlaUI (TestStack.Whiteの後継的位置づけ)
Playwright for .NET (Web移行する場合)

テストシナリオ

「書式による入力制限」→「テキストコントロール」ページに遷移して、テキストボックスに「2212」と入力し、スクリーンショットを撮影するテストを作成します。

<TestMethod>
Public Sub TestTextBoxInput()
    ' ツリーメニューで「書式による入力制限」を展開
    ExpandTreeNode("書式による入力制限")

    ' 「テキストコントロール」を選択
    ClickTreeNode("テキストコントロール")

    ' テキストボックスに「2212」を入力
    Dim textBox = mainWindow.Get(Of TextBox)(SearchCriteria.ByAutomationId("gcTextBox1"))
    textBox.Text = "2212"

    ' 検証
    Assert.IsTrue(textBox.Text.Contains("2212"))
End Sub

...のはずが、「要素が見つかりません」エラーで何度も失敗しました。

問題1: 要素が見つからない

原因

AutomationIdだけでは要素が見つからないケースがありました。

解決策: 3段階の段階的検索

「段階的検索」とは、最初の方法が失敗した時に、自動的に別の方法を試す仕組みのことです。

例えば、ATMでカードが読み取れない時に手入力に切り替わる、ネットワーク接続が切れた時に4Gに切り替わる、といった「代替手段の自動切り替え」です。

本記事では、要素を見つけるために以下の3段階の方法を順番に試す戦略を取りました：

AutomationIdで検索（最優先・高速）
座標範囲で推測（代替手段1・中速）
全コントロールダンプ（代替手段2・デバッグ用）

ソースコードからの情報抽出が、この戦略を実現する鍵でした。

ステップ1: Designer.vbから情報を取得

' InputMan/02_Format/GcTextBox.Designer.vb
Me.gcTextBox1.Name = "gcTextBox1"                    ' AutomationId
Me.gcTextBox1.Location = New System.Drawing.Point(8, 29)  ' 座標
Me.gcTextBox1.Size = New System.Drawing.Size(260, 24)     ' サイズ

この情報を使って、3段階の検索戦略を実装しました。

ステップ2: 3段階の段階的検索の実装

' 方法1: AutomationIdで検索（最優先）
Dim textBox As UIItem = Nothing
Try
    textBox = mainWindow.Get(Of TextBox)(SearchCriteria.ByAutomationId("gcTextBox1"))
    Console.WriteLine("✓ AutomationIdで見つかりました")
Catch ex As Exception
    Console.WriteLine($"✗ AutomationId検索失敗: {ex.Message}")
End Try

' 方法2: 座標範囲で推測（代替手段）
If textBox Is Nothing Then
    Console.WriteLine("すべてのTextBoxを検索中...")
    Dim allTextBoxes = mainWindow.GetMultiple(
        SearchCriteria.ByControlType(GetType(TextBox), WindowsFramework.Win32))

    For Each tb In allTextBoxes
        Dim loc = tb.Location
        Console.WriteLine($"TextBox: Id={tb.Id}, Location=({loc.X},{loc.Y})")

        ' Designer.vbの情報を活用: Location = (8, 29)
        ' 範囲で検索（左上付近 = X<100, Y<100）
        If loc.X < 100 AndAlso loc.Y < 100 Then
            textBox = tb
            Console.WriteLine("✓ 座標から推測成功")
            Exit For
        End If
    Next
End If

' 方法3: デバッグ用に全コントロールダンプ
If textBox Is Nothing Then
    DumpAllControls(mainWindow)
    Assert.Fail("テキストボックスが見つかりませんでした")
End If

ポイント

AutomationIdが最優先だが、失敗することもある
Designer.vbの座標情報を代替手段として活用
範囲検索なので、多少の位置ずれにも対応
デバッグ情報を詳細に出力してトラブルシューティングを容易に

制限事項: 実行時間の課題

3段階の段階的検索は確実性を高める一方で、実行時間の問題があります：

方法2（全TextBox検索）: ウィンドウ内の全コントロールを取得するため、コントロール数が多いと数秒かかる
方法3（全コントロールダンプ）: デバッグ用途だが、実行すると10秒以上かかることもある

実用性を考慮した運用:

本番環境ではAutomationIdのみに絞り、代替検索は開発・デバッグ時のみ有効化
または、タイムアウト設定を追加し、一定時間を超えたら処理をスキップ
UI構造が安定している場合は、座標検索も無効化してシンプルな実装にする

この課題は、TestStack.Whiteの仕様上避けられない部分があり、大規模なUIを持つアプリケーションでは特に顕著です。

問題2: 試用版ダイアログが出現

アプリ起動時に「ライセンスについて」ダイアログが表示され、テストがブロックされました。

解決策: 公式かビルド済みexeファイルを持っていく。

色々試行錯誤しましたが、難航しましたので公式サイトからexeを落としました。
https://developer.mescius.jp/inputmanplus-winforms/demo/inputman-winforms

問題3: ウィンドウが画面外にある

初回実行時、ウィンドウが座標(-1152, 113)に配置されていて、クリック操作が失敗しました。

解決策: ウィンドウ位置の自動調整

' ウィンドウを画面内に移動
Dim currentLoc = mainWindow.Location
If currentLoc.X < 0 OrElse currentLoc.Y < 0 OrElse
   currentLoc.X > 1920 OrElse currentLoc.Y > 1080 Then
    Console.WriteLine("ウィンドウが画面外にあります。画面内に移動します...")

    ' 最大化してから通常サイズに戻す
    mainWindow.DisplayState = DisplayState.Maximized
    Thread.Sleep(500)
    mainWindow.DisplayState = DisplayState.Restored
    Thread.Sleep(500)

    mainWindow.Focus()
    Console.WriteLine($"✓ ウィンドウを移動しました")
End If

スクリーンショット機能

テストの各段階でスクリーンショットを自動撮影する機能も実装しました。

Private Sub CaptureScreenshot(fileName As String)
    Try
        Dim screenshotDir = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Screenshots")
        Directory.CreateDirectory(screenshotDir)

        Dim timestamp = DateTime.Now.ToString("yyyyMMdd_HHmmss")
        Dim filePath = Path.Combine(screenshotDir, $"{timestamp}_{fileName}.png")

        ' 画面全体をキャプチャ
        Dim bounds = WinForms.Screen.PrimaryScreen.Bounds
        Dim bitmap As New Drawing.Bitmap(bounds.Width, bounds.Height)
        Using g = Drawing.Graphics.FromImage(bitmap)
            g.CopyFromScreen(bounds.Left, bounds.Top, 0, 0, bounds.Size)
        End Using
        bitmap.Save(filePath, Drawing.Imaging.ImageFormat.Png)

        Console.WriteLine($"✓ スクリーンショット保存: {filePath}")
    Catch ex As Exception
        Console.WriteLine($"✗ スクリーンショット撮影エラー: {ex.Message}")
    End Try
End Sub

撮影タイミング

' ページ遷移後
CaptureScreenshot("01_TextControlPage_Loaded")

' 入力前
CaptureScreenshot("02_Before_Input")

' 入力後
CaptureScreenshot("03_After_Input")

' エラー時（Catch句）
CaptureScreenshot($"Error_{DateTime.Now:HHmmss}")

プロジェクト構成

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="MSTest" Version="4.0.1" />
    <PackageReference Include="TestStack.White" Version="0.13.3" />
  </ItemGroup>

  <ItemGroup>
    <Reference Include="System.Drawing" />
    <Reference Include="System.Windows.Forms" />
    <Reference Include="WindowsBase" />
    <Reference Include="UIAutomationTypes" />
    <Reference Include="UIAutomationClient" />
  </ItemGroup>
</Project>

テスト実行

# InputManアプリをビルド
cd InputMan
msbuild /p:Configuration=Debug /p:Platform=x86

# テスト実行
cd E2ETests
dotnet test --logger "console;verbosity=detailed"

実行結果

===== テスト開始: テキストコントロールに「2212」を入力 =====
ステップ1: ツリーメニューを探索...
✓ ツリーノード展開: 書式による入力制限
ステップ2: テキストコントロールを選択...
✓ ツリーノードクリック: テキストコントロール
✓ スクリーンショット保存: ...\01_TextControlPage_Loaded.png
ステップ3: テキストボックスを検索...
✓ AutomationIdで見つかりました: gcTextBox1
✓ スクリーンショット保存: ...\02_Before_Input.png
ステップ4: テキスト「2212」を入力...
✓ 入力完了: 2212
✓ スクリーンショット保存: ...\03_After_Input.png
ステップ5: 入力結果を検証...
実際の値: [2212]
===== テスト成功 =====

合格!  - 失敗:     0、合格:     1、スキップ:     0、合計:     1、期間: 7 秒

VisualStudio2022 communityで実行した場合画像
実行時の画面

実行後のテストエクスプローラー

スクリーンショットを確認できます。
期待通り（テキストボックスに値が入っている）の画面が得られていることを確認できます。

ベストプラクティス

この経験から学んだベストプラクティスをまとめます。

✅ やるべきこと

ソースコードを活用する
- Designer.vbからAutomationIdと座標を確認
- MainForm.vbからアプリケーション構造を理解
3段階の段階的検索
- AutomationId → 座標範囲 → 全ダンプの順で検索
- 単一の方法に依存しない
詳細なログを出力
- 各ステップでConsole.WriteLine()を出力
- エラー時のデバッグが劇的に楽になる
スクリーンショットを活用
- 操作前後とエラー時に自動撮影
- 目視確認で問題を素早く特定
適切な待機時間
- Thread.Sleep()でページ遷移やダイアログを待機
- 環境によって調整が必要
try-catchでエラーハンドリング
- エラー時のスクリーンショットとログ出力
- 失敗原因の特定が容易に

❌ 避けるべきこと

絶対座標への依存
- 画面解像度やDPI設定で変わる
- 範囲検索ならある程度柔軟
待機時間なし
- UIの描画が間に合わない
- 不安定なテストになる
エラーハンドリングなし
- 失敗時の原因特定が困難
- デバッグに時間がかかる
ログなし
- 何が起きているか分からない
- トラブルシューティングが不可能

ソースコードの重要性

今回、ソースコードにアクセスできたことが成功の鍵でした。

Designer.vbから以下の情報を取得できたおかげで、座標範囲による検索が可能になりました：

Me.gcTextBox1.Name = "gcTextBox1"
Me.gcTextBox1.Location = New System.Drawing.Point(8, 29)
Me.gcTextBox1.Size = New System.Drawing.Size(260, 24)

ソースコードがない場合は、Inspect.exe（Windows SDKツール）でAutomationIdを調査する必要があります。

効果

生成AIによる開発効率化

生成AI（Claude CodeやGitHub Copilot）を活用したことで、E2Eテスト開発が劇的に効率化されました：

コード生成の高速化: 基本的なテストコードの雛形をAIが数秒で生成
問題解決の迅速化: 「要素が見つからない」問題に対して、AIが3段階の段階的検索を提案
ベストプラクティスの習得: AIとの対話を通じて、E2Eテストの設計パターンを学習
エラー対応の効率化: エラー発生時にAIがログを分析し、解決策を提示

従来の手作業との比較:

試行錯誤によるコード修正: 手動で数時間 → AIとの対話で30分以内
ベストプラクティスの調査: 複数のドキュメント検索 → AIが即座に提案
エラーハンドリングの実装: 段階的に追加 → 初回から包括的な実装

AIツールについて: 本記事ではClaude Codeを使用しましたが、GitHub Copilot Chat、Claude API、その他のコーディング支援AIでも同様の効果が期待できます。

導入の容易性

TestStack.White + MSTestの組み合わせにより、Visual Studioまたはdotnet CLIがあればすぐに導入可能です。.NET Framework 4.8環境があれば、パッケージのインストールだけで開始できます。

生成AIの活用により、未経験者でもE2Eテストの導入が可能になりました。

導入工数

生成AI活用により、プロジェクト作成からテスト実行まで約2-3時間で完了しました。

従来の手作業では5-6時間かかっていた作業が、AIとの対話により半分以下に短縮：

プロジェクト作成とパッケージインストール: 15分（AI支援で設定ミスを回避）
初回テストコード作成と要素検索戦略の確立: 1.5時間（AIがコード生成＋戦略提案）
スクリーンショット機能とエラーハンドリングの実装: 30分（AIが包括的な実装を提案）
ダイアログ処理とウィンドウ位置調整の実装: 30分（AIが複数の解決策を提示）

削減効果

手動テストと比較して、以下の効果が得られました：

回帰テストの実行時間: 手動5分 → 自動7秒（約40倍の高速化）
スクリーンショット撮影: 手動作業不要（3枚自動撮影）
再現性: 手動テストでは再現が困難だった画面外ウィンドウの問題も自動検出
デバッグ効率: 詳細ログとスクリーンショットにより、失敗原因の特定時間を約10分削減

3段階の段階的検索により、要素が見つからない問題の発生率を大幅に削減し、安定したE2Eテストを実現できました。

変更に強いシステムへ

E2Eテストの導入により、システム全体の保守性と長期的な品質が大幅に向上します：

日常的な開発での安心感

リファクタリングの安全性: 内部実装を変更しても、E2Eテストが通れば外部仕様は維持されていることが保証される
機能追加時の退行防止: 新機能追加時に既存機能が壊れていないことを自動検証し、デグレードを未然に防ぐ
コードレビューの効率化: テストが品質を保証するため、レビュアーは仕様適合性の確認に集中できる

実行可能なドキュメントとしての価値

仕様の明文化: E2Eテストが「システムがどう動くべきか」を示す実行可能なドキュメントとして機能
新メンバーのオンボーディング: テストコードを読むことで、システムの期待動作を具体的に理解できる
仕様書との乖離防止: コードと仕様書が別々だと乖離が起きるが、テストコードは常に最新の仕様を反映

チーム開発での品質向上

属人性の排除: 特定の担当者がいなくても、テストが動作を保証
品質のセーフティネット: 他のメンバーが変更を加えても、テストが破壊的な変更を検出
CI/CD パイプラインへの統合: 自動テストにより、マージ前に品質を確認できる

長期的な投資効果: 初期投資（E2Eテスト構築）は2-3時間ですが、保守フェーズでの品質担保、デバッグ時間の削減、仕様確認の効率化により、年間で数十〜数百時間の工数削減が見込めます。特にレガシーシステムの長期保守では、この効果は累積的に大きくなります。

まとめ

生成AI（Claude Code、GitHub Copilotなど）を活用することで、Windows FormsアプリケーションのE2Eテスト開発が大幅に効率化されました。

技術的なポイント

E2Eテストを安定して動作させるために押さえるべきポイント：

3段階の段階的検索で要素を確実に見つける（AIが戦略を提案）
ソースコードから情報を抽出して段階的検索を実装（AIがDesigner.vbの活用方法を提示）
詳細なログとスクリーンショットでデバッグを効率化（AIが包括的な実装を生成）
.NET移行時は別フレームワークへの移行を考慮（AIが代替技術を提示）

生成AI活用の効果

開発時間: 従来5-6時間 → AI活用で2-3時間（約50%削減）
品質向上: 初回から包括的なエラーハンドリングとログ機能を実装
学習効果: AIとの対話を通じてE2Eテストのベストプラクティスを習得

「要素が見つからない」問題は、E2Eテストの最大の壁ですが、生成AIの支援により、適切な戦略を迅速に導入できます。

E2Eテスト自動化に課題を感じている方は、ぜひ生成AI（Claude Code、GitHub Copilot、その他のコーディング支援AI）の活用を検討してみてください。どのツールを使用しても、本記事で紹介した3段階の段階的検索などのアプローチは有効です。

参考資料

今回のgithub commit分

サンプルコード

完全なサンプルコードは以下のリポジトリで公開します：

masius-legacy-and-ai-develop
├── E2ETests
│   ├── TextBoxControlTest.vb
│   ├── E2ETests.vbproj
│   └── README.md
└── .github
    └── e2e-testing-inputman.md  # 詳細ガイド

Windows Formsアプリケーションの保守・改善に取り組んでいる方の参考になれば幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up