Unit tests を書く

Flutter のテストは次の３つに分類されます。

• Unit tests
• Widget tests
• Integration tests

Unit tests は、他のテストより依存関係を少なくすることができるため、実装やメンテナンスコストを低く抑えることができます。

実際に Unit tests を書いていきましょう。

課題

• yumemi_weather API の呼び出しから Widget へ通知する部分までの Unit tests を書く
  • 依存しているものが、成功・失敗するケースも網羅する
• 余力があれば、JSON のエンコード・デコードの Unit tests も書く

※ テストコードを書くにあたって、依存関係を見直すなどのリファクタリングを行っても問題ありません。

ヒント

テストを書くときは、依存しているものは何で、前提条件と完了条件は何なのかを明確にすることが重要です。

また、Mockito を使って依存しているものをモックすることで、様々なテストケースに柔軟かつ簡単に対応できるようになります。

参考資料

• Riverpod Testing

課題の準備をする

課題をスムーズに進めるための準備をしましょう。

課題

• 作成した研修用のリポジトリにメンターを招待して、リポジトリへの書き込みアクセス権を付与
• 作成した研修用のリポジトリの GitHub Actions の権限を「Allow all actions and reusable workflows」に設定
• 作成した研修用のリポジトリの GitHub Actions のワークフローの権限を「Read and write permissions」に設定
• 作成した研修用のリポジトリに main ブランチの保護ルールを追加
  • マージ前にプルリクエスト必須
  • マージ前に１人の承認を必須
  • マージ前にステータスチェック必須
  • マージ前にブランチ最新化必須
  • マージ前に会話の解決必須
  • フォースプッシュを許可しない
  • 削除を許可しない
• 使用しているチャットツールで GitHub 通知の購読設定
  • Slackコマンド: /github subscribe ユーザー名/リポジトリ名 issues pulls reviews comments
• 作成した研修用のリポジトリを git clone [url] して、ローカルにコピー
• fvm をインストール
• プロジェクトルートで fvm install コマンドを実行して対象の Flutter SDK をインストール
• IDE の最新安定板をインストール
• Flutter の設定（ fvm flutter doctor を実行して確認）
• Android・iOS でアプリを実行
• .github/workflows-templates ディレクトリを .github/workflows にリネーム
• review-assign.yaml の REVIEWERS にメンターの GitHub のユーザー名を設定

参考資料

• リポジトリの GitHub Actions の設定を管理する
• 保護されたブランチについて
• GitHub + Slack

天気予報アプリの画面レイアウトを構成する

課題

以下の条件の画面レイアウトを作ってみましょう。

• Placeholder の幅は画面の幅の半分

• 青字と赤字の Text の幅は Placeholder の幅の半分
  

• Placeholder の高さと幅は同じ
  

• Text の上下に 16 logical pixel のパディング

• Text の文字は ** ℃

• Text の水平位置は**

• Text のスタイルは TextTheme の labelLarge

• Text の色は左が Colors.blue、右が Colors.red
  

• Placeholder の水平**は画面の**と同じ

• Placeholder と Text を合わせた矩形の垂直**は画面の**と同じ
  

• Text と TextButton の隙間は 80 logical pixel
  

• Text と TextButton の水平**は同じ
  

ヒント

Flutter には iOS の NSLayoutConstraint や Android の ConstraintLayout のようなものはありません。

以下の Widget を利用するとさまざまな画面に対応することができます。

• Row
• Column
• Flexible
• Expanded
• AspectRatio
• FractionallySizedBox

Flutter Inspector を利用すると、レイアウト構造を視覚化でき、より開発しやすくなります。
便利な機能がたくさんあるので、実際に試しながらしっかり読み込んでおきましょう。

JSON を扱う

yumemi_weather の API を切り替えて、より詳細な天気予報を取得して表示しましょう。

課題

• 使用する API を fetchThrowsWeather() から fetchWeather() に変更する
• API から受け取った天気状況・最低気温・最高気温を画面に表示する

動作イメージ

ヒント

Dart にはデフォルトで JSON を変換する仕組み が用意されています。

スレッドブロック

時間のかかる処理を扱ってみましょう。

課題

• 使用する API を fetchWeather() から syncFetchWeather() に変更する
• API の処理が戻るまで CircularProgressIndicator を表示する

動作イメージ

ヒント

Dart の実行モデルはシングルスレッド・イベントループです。

そのため、そのままだと画面が固まってしまい CircularProgressIndicator は表示されません。

よって、このようにスレッドをブロックしてしまうような処理の場合は isolates を使用します。

参考資料

• Flutter で Isolate を用いた並列処理をするべきシーンとそのやり方

状態管理を見直す

setState や InheritedWidget をそのまま用いる方法は、階層が深くなってしまったり、コード量が多くなってしまったりなどの課題があるため、Riverpod
などの外部パッケージを利用する人が多いのではないでしょうか。

Flutter での状態管理の方法について、公式からいくつか紹介されています。

• List of state management approaches

その中で Provider が推奨されていますが、Provider にあったいくつかの課題を解決した改良版が Riverpod です。

Riverpod を導入して、状態管理やアーキテクチャを見直してみましょう。

課題

• Riverpod を導入して、天気予報画面の状態管理を見直す
• アーキテクチャを見直し、ARCHITECTURE.md に記載する

ヒント

Different Types of Providers に Provider の種類とそれぞれの違いがまとめられています。

Provider の依存関係図の例：

flowchart TB
  subgraph Arrows
    direction LR
    start1[ ] -..->|read| stop1[ ]
    style start1 height:0px;
    style stop1 height:0px;
    start2[ ] --->|listen| stop2[ ]
    style start2 height:0px;
    style stop2 height:0px; 
    start3[ ] ===>|watch| stop3[ ]
    style start3 height:0px;
    style stop3 height:0px; 
  end

  subgraph Type
    direction TB
    ConsumerWidget((widget));
    Provider[[provider]];
  end
  WeatherPage((WeatherPage));
  weatherPageUiStateProvider --> WeatherPage;
  fetchWeatherUseCaseProvider -.-> WeatherPage;
  WeatherForecastPanel((WeatherForecastPanel));
  weatherForecastPanelUiStateProvider ==> WeatherForecastPanel;
  weatherPageUiStateProvider[[weatherPageUiStateProvider]];
  fetchWeatherUseCaseProvider[[fetchWeatherUseCaseProvider]];
  weatherRepositoryProvider ==> fetchWeatherUseCaseProvider;
  weatherUiStateRepositoryProvider ==> fetchWeatherUseCaseProvider;
  weatherForecastPanelUiStateProvider[[weatherForecastPanelUiStateProvider]];
  weatherRepositoryProvider[[weatherRepositoryProvider]];
  weatherDatastoreProvider ==> weatherRepositoryProvider;
  weatherUiStateRepositoryProvider[[weatherUiStateRepositoryProvider]];
  weatherDatastoreProvider[[weatherDatastoreProvider]];

参考資料

• Flutterの状態管理手法の選定
• 【2021年版】Flutterの状態管理パターン総まとめ

天気予報を取得し、表示する

yumemi_weather の API を使用して、天気予報を取得しましょう。

課題

• Reload ボタンをタップして天気予報を取得する
• 天気予報を画面に表示する

使用する API

• fetchSimpleWeather()

利用する画像

• sunny
• cloudy
• rainy

動作イメージ

ヒント

Flutter で SVG を表示するときは、flutter_svg を利用すると簡単に表示できます。

API のエラーハンドリング

yumemi_weather の API のエラーを補足して、ダイアログを表示しましょう。

課題

• 使用する API を fetchSimpleWeather() から fetchThrowsWeather() に変更する
• API のエラーを補足して、エラーの内容に応じて AlertDialog でメッセージを表示する
  • メッセージの内容は自由
• AlertDialog の OK ボタンをタップすると、ダイアログを閉じる

動作イメージ

※ エラーメッセージは仮で設定しています。

ヒント

天気予報ページと天気予報パネルの状態をそれぞれ別で考えると整理しやすくなるかもしれません。

シリアル化する

多くのアプリでは外部 API とのやりとりが行われます。

そして、多くの場合データの受け渡しは JSON が使われます。

Dart にはデフォルトで JSON を変換する仕組み が用意されていますが、独自に作成したクラスへ変換しようとすると、自分で fromJson() や toJson()
を実装しなければならずコストがかかってしまい、さらにリスクも高くなってしまいます。

そこで、公式からは json_serializable というパッケージが紹介されています。

課題

• json_serializable を利用して、独自のクラスから API のリクエストを作成する
• json_serializable を利用して、API のレスポンスを独自のクラスに変換する

※ freezed を利用しても問題ありません

ヒント

build.yaml を作成すると、一括で様々な設定ができます。

参考資料

IDE の機能をうまく活用すると、素早くクラスを作成できるためおすすめです。

Visual Studio Code

• Extension
• Snippets

JetBrains IDEs

• Plugins
• Live templates

StatefulWidget のライフサイクル

Flutter の StatefulWidget にも、iOS の UIViewController や Android の Activity のようなライフサイクルがあります。

iOS・Android と異なる点があるため、きちんと確認しておきましょう。

課題

• StatefulWidget を継承した Widget で構築された新しい画面を追加する
• 新しい画面の背景色は Colors.green に設定する
• アプリ起動時に新しい画面に遷移する
• 新しい画面が表示されたら、0.5 秒後に前回まで作っていた画面に遷移する
• 前回まで作っていた画面の Close ボタンをタップすると画面を閉じる

動作イメージ

ヒント

WidgetsBinding.instance.endOfFrame を利用すると、画面の描画が終わってから処理を実行することができます。

画面遷移は外部パッケージを利用しても問題ありませんが、本課題では Navigator の命令型 API を利用すると比較的簡単に実装できます。

参考資料

• How do I listen to iOS lifecycle events?
• How do I listen to Android activity lifecycle events?

Widget tests を書く

次は Widget tests を書いていきましょう。

課題

• 次の Widget tests を書く
  • 特定の条件で、天気予報画面に晴れの画像が表示されること
  • 特定の条件で、天気予報画面に曇りの画像が表示されること
  • 特定の条件で、天気予報画面に雨の画像が表示されること
  • 特定の条件で、天気予報画面に最高気温が表示されること
  • 特定の条件で、天気予報画面に最低気温が表示されること
  • 特定の条件で、天気予報画面にダイアログが表示され、特定のメッセージが表示されること
• 余裕があれば、他の Widget tests も書く

ヒント

状態管理方法やアーキテクチャなどによって、特定の条件の詳細が変化します。

Session9 と同じで、テストを書くときは、依存しているものは何で、前提条件と完了条件は何なのかを明確にすることが重要です。

参考資料

• Riverpod Testing

Mixin パターン

Dart には Mixin という機能があり、公式パッケージから AutomaticKeepAliveClientMixin や TextSelectionDelegate などの便利なものがいくつか提供されています。

実際に Mixin を作成して使ってみましょう。

課題

• レイアウトが表示された後に「何かしらの処理」を行う Mixin を作成する
• 作成した Mixin の使用先で「何かしらの処理」を記述できるようにする
• Session3 で作成した以下の処理を作成した Mixin を使って書き直す

  新しい画面が表示されたら、0.5 秒後に前回まで作っていた画面に遷移する

ヒント

on キーワードによって Mixin の使用を制限することができます。

さらに、on キーワードで指定したクラスのメソッドをオーバーライドすることもできます。

参考資料

Mixin とは

Mixin または Mix-in（ミックスイン）は、オブジェクト指向プログラミングで用いられる技法であり、他のクラスから
使用されるメソッド群を持つクラスが、他のクラスのスーパークラスにならないで済むための、特別な多重継承関係を
実現するためのメカニズムを意味している。Mix-in されたメソッドに、他のクラスがアクセスする方法はそれぞれの
言語仕様に依存している。

Mix-in はコードの再利用性を促進し、従来のクラスの多重継承がもたらしていた菱形継承などの数々の問題を回避する。
多重継承を採用していない言語においては、多重継承と類似の機能性をより堅牢にして提供する。
依存性逆転の原則のデザインパターンにも応用されている。

出典: フリー百科事典『ウィキペディア（Wikipedia）』

Mixin の採用言語例

• Scala - トレイト
• Ruby - モジュール
• Kotlin - インターフェース
• Swift - プロトコル
• JavaScript - 関数オブジェクト