アプリの機能が多ければ多いほど、手動でテストするのは難しくなります。 自動テストは、機能とバグ修正の速度を維持しながら、アプリを公開する前にアプリが正しく実行されることを確認するのに役立ちます。
注：Flutterアプリをテストする実践的な練習については、Flutterアプリのコードラボをテストする方法を参照してください。
- 自動テストはいくつかのカテゴリに分類されます。
- 単体テストは、単一の関数、メソッド、またはクラスをテストします。
- ウィジェットテスト（コンポーネントテストと呼ばれる他のUIフレームワーク）は、単一のウィジェットをテストします。
- 統合テストは、アプリ全体またはアプリの大部分をテストします。
| Unit | Widget | Integration | |
|---|---|---|---|
| Confidence(信頼性) | Low | Higher | Highest |
| Maintenance cost
(メンテナンスコスト) |
Low | Higher | Highest |
| Dependencies
(依存性) |
Few | More | Most |
| Execution speed
(実行スピード) |
Quick | Quick | Slow |
Contents
Unit tests
Widget tests
ウィジェットテスト（コンポーネントテストと呼ばれる他のUIフレームワーク）は、単一のウィジェットをテストします。
ウィジェットテストの目的は、ウィジェットのUIが期待どおりに表示され、相互作用することを確認することです。
ウィジェットのテストには複数のクラスが含まれ、適切なウィジェットライフサイクルコンテキストを提供するテスト環境が必要です。
たとえば、テスト対象のウィジェットは、ユーザーのアクションとイベントを受信して応答し、レイアウトを実行し、子ウィジェットをインスタンス化できる必要があります。
したがって、ウィジェットテストは単体テストよりも包括的です。 ただし、単体テストと同様に、ウィジェットテストの環境は、本格的なUIシステムよりもはるかに単純な実装に置き換えられます。
Recipes
Integration tests
統合テストは、アプリ全体またはアプリの大部分をテストします。 統合テストの目標は、テスト対象のすべてのウィジェットとサービスが期待どおりに連携して機能することを確認することです。 さらに、統合テストを使用してアプリのパフォーマンスを確認できます。
通常、統合テストは、実際のデバイス、またはiOSシミュレーターやAndroidエミュレーターなどのOSエミュレーターで実行されます。 テスト対象のアプリは通常、結果の偏りを避けるためにテストドライバーコードから分離されています。
Recipes
Continuous integration services
継続的インテグレーション（CI）サービスを使用すると、新しいコードの変更をプッシュするときにテストを自動的に実行できます。 これにより、コードの変更が期待どおりに機能し、バグが発生しないかどうかについてタイムリーなフィードバックが提供されます。
さまざまな継続的インテグレーションサービスでテストを実行する方法については、以下を参照してください。
- Continuous delivery using fastlane with Flutter
- Test Flutter apps on Appcircle
- Test Flutter apps on Travis
- Test Flutter apps on Cirrus
- Codemagic CI/CD for Flutter
- Flutter CI/CD with Bitrise
参考