JOURNAL

Flutter のテストは unit・widget・integration の三層に分かれる。それぞれが何を速く・何を現実に近く検証するのか、依存の差し替え方まで含めて、最小の実コードで整理する。連載の最終回。

非同期処理の完了時、Widget はすでに破棄されていることがある。await をまたいで setState や BuildContext を使う前に、なぜ mounted・context.mounted を確認するのかを短く整理する。

サーバーや DB から届くデータには loading・data・error の三状態がある。Dart の Future/async/await を土台に、Riverpod の AsyncValue と FutureProvider で三状態をひとつの型として扱い、UI へ落とし込む。

共有状態は Widget の外に持ち出す。Riverpod で状態を宣言し、それを読む三つの入口 watch・read・listen の違いと使い分けを、最小の実コードで整理する。

Widget が不変なら、変化する状態はどこに置くのか。StatelessWidget と StatefulWidget の使い分け、setState が再描画を起こす仕組み、State のライフサイクル、そしてローカル状態と共有状態の境界を整理する。

Widget は画面そのものではなく、状態から UI を導く不変の設計図。build() が何度も呼ばれてよい理由、BuildContext が表す「ツリー上の位置」、そして小さな Widget へ分ける基準を整理する。

Flutter アプリは Dart の main() から始まり、最初のフレームが描かれるまでに決まった順序で処理が進む。その流れを最小の実コードで追い、初期化・エラー捕捉・実行時設定を「どこに置くか」を掴む。