すべてを E2E テストにすると失敗箇所を探すのに時間がかかる。一方、ViewModel だけではボタンが押せないことやエラー文が隠れることを見落とす。故障の境界に合わせてテストを選ぶ。

三つの層に役割を与える

Repository の単体テストはキャッシュ、エラー変換、オフラインキュー、版の競合を偽の時計と通信で検証する。Widget テストは更新中も注文を表示すること、空状態の作成導線、権限エラー時の操作無効化を確認する。統合テストはログイン、注文作成、断線後の復旧など重要な少数の経路に絞る。

失敗を説明可能にする

ID と時刻を固定し、非同期画面では一定時間の sleep ではなく目的の状態を待つ。スクリーンショット比較は安定した主要レイアウトに使い、振る舞いの検証に置き換えない。文字サイズや OS によるピクセル差も考慮する。

画面遷移、権限、永続化は実機またはエミュレーターで確かめ、細かな状態遷移は速い下位テストに置く。参考：Flutter テスト概要。

一件の送金でテストの組合せを作る

送金には金額検証、受取人照会、確認画面、送信、結果画面がある。金額の上限、通貨の精度、残高、手数料は Widget に依存しないロジックに置き、境界値と丸めを単体テストする。これらは速く、変更のたびに実行できる。次に偽のリポジトリと制御可能な時計を注入し、Widget テストで入力エラー、読込中、確認、失敗後の復旧を調べる。文言の存在だけでなく、送信中の連打防止、失敗後の再試行、古い応答による新しいフォームの汚染を確認する。

統合テストは少数の重要な流れに絞る。ログイン、送金画面、受取人確認、送信、履歴の確認などだ。分離されたアカウントとデータを持つ制御可能なテストバックエンドか、明示したシミュレーターを使い、実際の送金網を CI の依存にしない。システムキーボード、権限ダイアログ、ディープリンクからの復帰、背景への移動は対象 OS 上でも確認する。Widget テストだけでは代替できない。

層	主な問い	確認例
単体	計算規則は正しいか	通貨精度、手数料、境界金額
Widget	UI は復旧できるか	二重送信防止、失敗後の再試行
統合	部品が協調するか	一回の送信で記録は一件
実機	OS の動作は適切か	キーボード、復帰、弱い通信

テスト用の偽物で競合を隠さない

偽リポジトリは常に即成功させず、応答順をテストが決められるようにする。競合する送信、離脱後の応答、サーバーは成功したが端末ではタイムアウトした場合、結果画面への二重遷移を試す。成功の判断はサーバーの冪等な結果に基づき、テストで仮定した遷移回数から推測しない。参考：Flutter テスト概要。