Flutter のテストを三つの層で理解する

ここまでで、起動フロー・Widget ツリー・状態・Riverpod・非同期と、画面のコードを読む道具がそろいました。連載の最後は、そのコードを守る側——テストです。

Flutter のテストは種類がいくつかあって、最初はどれを書けばいいか迷います。ですが分け方の軸は一つだけ。**「速く・狭く検証するか」対「遅く・現実に近く検証するか」**です。この軸で unit / widget / integration の三層を整理すれば、迷いはなくなります。

§ 01WHYなぜテストを分けるのか

テストには相反する二つの望みがあります。

速く・狭く: ミリ秒で終わり、ロジックだけを切り出して検証したい
現実に近く: 実際のアプリを動かし、画面遷移や通信までまるごと検証したい

両立はしないので、目的ごとに層を分けます。

unit … UI に依存しない純粋なロジック
widget … 単一画面の描画と操作
integration / E2E … アプリ全体を通したユーザーフロー

そして数のバランスはピラミッドにします。土台に速い unit を厚く、真ん中に widget を適度に、頂点に遅い E2E を少しだけ。速いテストで大半を守り、遅いテストは要所に絞る、という配分です。

§ 02UNITロジックを単体で検証する

計算、判定、変換、そして Notifier の状態遷移のように、UI を描かずに確かめられるものが unit テストの対象です。レンダリングを伴わないので高速です。

Provider を検証するときは、Widget を立てずに ProviderContainer を使います¹。

test/unit/counter_test.dartDART

test('increment で state が 1 増える', () {
  final container = ProviderContainer();
  addTearDown(container.dispose);
 
  expect(container.read(counterProvider), 0);
  container.read(counterProvider.notifier).increment();
  expect(container.read(counterProvider), 1);
});

操作（increment）の後に、状態がどう変わったかを必ず検証します。呼んで終わりにせず、 expect で結果を確かめる——これがテストの最低条件です。

単一の画面やウィジェットの描画と操作を確かめるのが widget テストです。testWidgets の中で WidgetTester を使い、ウィジェットをテスト環境に描いて操作します。

pumpWidget(...) … ウィジェットを描く
pump() … 1 フレーム進める。pumpAndSettle() … アニメーションが収まるまで進める²
find.byIcon / find.text / find.byKey … 要素を探す（Finder）
tester.tap(...) … 操作する

test/widget/counter_screen_test.dartDART

testWidgets('+ ボタンで表示が 1 になる', (tester) async {
  await tester.pumpWidget(
    const ProviderScope(child: MaterialApp(home: CounterScreen())),
  );
  expect(find.text('0'), findsOneWidget);
 
  await tester.tap(find.byIcon(Icons.add));
  await tester.pump(); // 状態変更後のフレームを進める
 
  expect(find.text('1'), findsOneWidget);
});

操作（tap）の後に pump でフレームを進め、表示が変わったことを検証しています。要素を探すときは、画面全体からの文字列一致より、Key やセマンティクスで対象を特定するほうが壊れにくく、意図も明確になります³。

§ 04E2Eアプリ全体を通して検証する

integration_test を使うと、実際のアプリを端末やデスクトップで動かし、ログイン → 画面遷移 → 送信、のような一連のフローを端から端まで検証できます。遅く、環境も要りますが、いちばん現実に近い。

価値があるのは、モックでは再現できないレイヤー間の連鎖です。Provider の更新がルーターを動かし、画面が切り替わる——こうした配線の正しさは、各層を個別にモックした unit / widget では保証しきれません。だからこそ E2E は要所のユーザージャーニーに絞って書きます。

§ 05FAKE依存を差し替える

unit / widget を速く・決定的に保つには、通信や DB のような外部依存を偽物に差し替えます。連載第4回で触れた Provider の overrides が、ここで効いてきます。

DART

await tester.pumpWidget(
  ProviderScope(
    overrides: [
      itemRepositoryProvider.overrideWithValue(FakeItemRepository()),
    ],
    child: const MaterialApp(home: ItemsScreen()),
  ),
);

本物のリポジトリを FakeItemRepository に差し替えれば、ネットワークなしで、狙った状態を再現してテストできます。「Provider を依存性注入として使う」とは、まさにこの差し替えのことでした。

§ 06RULE何をどの層で

層	何を	速さ	使いどころ
unit	純粋なロジック・状態遷移	速い	計算・判定・Notifier
widget	単一画面の描画と操作	中	画面単体の UI
E2E	アプリ全体のフロー	遅い	画面をまたぐ重要な導線

原則は 「ロジックは unit、単一画面は widget、画面をまたぐ現実の流れは E2E」。同じことを検証できるなら、より速い下の層に寄せる——これがピラミッドの意味です。

§ 07SUMMARY連載のまとめ

テストは speed 対 realism の軸で三層に分ける
unit … UI 抜きのロジック。ProviderContainer で Provider も検証
widget … testWidgets で描いて操作し、表示の変化を検証
E2E … integration_test で実アプリのフロー。配線の正しさを守る
fake … overrides で外部依存を差し替え、速く決定的に

これで連載は一周しました。起動 → Widget ツリー → 状態 → Riverpod → 非同期 → mounted → テスト。この 7 本で、Flutter の画面コードと Provider、そしてそれを守るテストを、「なぜそう書くか」まで含めて読めるはずです。

ここから先の Flutter Hooks、ナビゲーション、Freezed、ローカル保存といったテーマは、また別の連載で一つずつ掘り下げていきます。