Flutterのテスト

ユニットテストとWidgetテストとIntegrationテストがある。

ユニットテスト < Widgetテスト < Integrationテスト

上記の順で複雑度と信頼性が上がっていく。

2023/02/09 16:51:45

Flutterのテストをどのような手順で行っていくなどの考え方についてはこちらが参考になるかと。

英文ではあるが、こちらも参考になる。

QAエンジニアがプロジェクトにおいてテスト計画をどんな風に考えれば良いというのはこちらを参照。

テストの粒度などを考えるには以下が最も妥当な考え方。

Flutterには以上のように複数の種類のテストが用意されていますが、どのテストをどれくらい行えばいいのか、 また、どのようなケースに対してテストを用意すればいいのかは悩ましいところです。

元も子もないことを言ってしまえば、全てのテストを網羅的にかければテストの信頼性を最大化することができますが、 テストにそこまでの時間をかけることは現実的ではありませんし、 テストを書くこと自体が目的化してしまうようなことは避けるべきです。

開発体制やその他の状況によって理想的なテスト設計は微妙に違ってくることを前置きとした上で 筆者の推奨するテスト設計は以下のようなものです。

状態管理に関してはWidgetからできるだけ切り離した上で網羅的にUnit Testを書く。

Widgetテストは固有の機能を持つ汎用的なカスタムWidgetに関しては書く。 既存のWidgetを組み合わせただけのWidgetに対してはテストを書かない。

統合テストは必要になるまで書かない。ログインや決済などアプリの重要な機能や外部依存が強い機能に関して必要あれば書く。

テストのカバレッジとしてはUnit Test > Widget Test >>> Integration Testの順で小さくなっていきます。

基本的にUnit Testでほとんどのテストができることが重要です。そのためテストの設計だけでなく、アプリケーション全体の 設計からテスト容易性に気をつけておくことが重要です。Flutterアプリの設計に関しては21日目から23日目の記事で重点的に 扱っていきます。

既存のWidgetを組み合わせただけのWidgetに対するテストは有効なテストにならないことが多いです。 これは、多くのWidgetはコンストラクタから渡されたものを表示するだけのStatelessWidgetで、テストケースが 自明なものになりやすいからです。 逆に再利用可能なWidgetに関しては様々なユースケースを想定する必要があるので、 テストのコストパフォーマンスが大きくなりやすい傾向があります。

統合テストに関しては、よくテストされた部分の組み合わせであればあるほど効果が薄くなります。 もちろんOSのバージョンによる違いや、OSから提供されているAPIへアクセスする機能など、 統合テストでしかカバーできない範囲があることは事実なので、そういったケースに限り部分的に導入することはあります。

個人的にはFirebase Test LabのFlutterサポートに 期待しています。複数のバージョンのOSで全自動の実機テストを行ってくれて、スクリーンショットも出してくれるので、 統合テストに期待する多くのケースに対応できそうです。

public.icon