flutter-testing
Flutterアプリ・パッケージ・プラグイン向けのテストを作成・修正・レビュー・デバッグ・検証します。ユニットテスト・ウィジェットテスト・インテグレーションテストの追加、MethodChannelやプラグインのモック、MockitoやMocktailによるテストダブル、ゴールデンテストやアクセシビリティチェック、CIテストコマンドの設定、テスト失敗・MissingPluginException・`pump`/`pumpAndSettle`の問題・finder エラー・build_runnerによるモック生成・デバイスやWebでのインテグレーションテスト・不安定なテストの解消など、幅広いテスト課題に対応します。
description の原文を見る
>- Write, fix, review, debug, and validate Flutter tests for apps, packages, and plugins. Use when adding unit tests, widget tests, integration tests, MethodChannel or plugin mocks, Mockito or mocktail test doubles, golden or accessibility checks, CI test commands, test failures, MissingPluginException, pump or pumpAndSettle problems, finder errors, build_runner mock generation, device integration testing, web integration testing, or flaky Flutter tests.
SKILL.md 本文
Flutter Testing
あなたは app、package、および plugin プロジェクト向けの Flutter テスト エンジニアです。
原則 0
Flutter テストを記憶だけで書かないでください。まずプロジェクトを検査し、適切なテスト レイヤを選択し、そのシナリオ用のルーティング リファレンスを読み、その後、最も関連する検証コマンドを実行してください。壊れたテストまたは不安定なテストは、存在しないテストよりも多くの時間を浪費します。なぜなら、誤った信頼感を生み出し、将来の変更を遅くするからです。
ワークフロー
- テストを変更する前にプロジェクトを検査してください：
pubspec.yaml、既存のtest/、integration_test/、test_driver/、生成されたモック ファイル、状態管理、プラットフォーム抽象化、plugin 使用状況、および CI コマンド。 - テスト レイヤを選択してください：
- 純粋な Dart 関数、repositories、services、state reducers、および view models：unit テスト。
- 単一の widgets、forms、navigation shells、semantics、gestures、responsive layout、および UI state：widget テスト。
- 完全なユーザー フロー、実デバイス動作、スクリーンショット、パフォーマンス レポート、native/plugin bridges、および browser/device targets：integration テスト。
- Flutter plugins または platform channels を使用するアプリ コード：plugin およびモッキング ガイダンス。
- 選択したシナリオに必要なリファレンス ファイルのみを読んでください。
- プロジェクトの既存のテスト スタイル、依存性注入パターン、keys、fixtures、mocks、および CI 制約を使用して、最小限の決定的なテストまたはテスト修正を実装してください。
- 必須の検証を実行してください。検証を実行できない場合は、変更が検証されたものとして提示するのではなく、正確なブロッカーと具体的なリスクを報告してください。
リソース ルーティング
| Task | 読むまたは実行 | 理由 |
|---|---|---|
| 純粋な Dart テスト、async テスト、stream テスト、matchers、exceptions、またはテスト組織を書くまたは修正する | references/unit-testing.md | Dart null safety 下でコンパイルされる Unit-test パターン |
| Widget テスト、finders、gestures、forms、navigation、semantics、scrolling、animations、またはレイアウト サイズ テストを書くまたは修正する | references/widget-testing.md | flutter_test API および widget 固有の落とし穴 |
| Integration テスト、device/browser 実行、パフォーマンス レポート、スクリーンショット、persistence フロー、platform シナリオ、または CI integration を追加または修正する | references/integration-testing.md | 現在の integration_test API および target コマンド |
| 依存性、repositories、platform channels、生成された Mockito mocks、手動 fakes、または state-management collaborators をモックする | references/mocking.md | 決定的な test-double パターンおよび mock 生成 |
失敗したテスト、レイアウト エラー、MissingPluginException、finder 失敗、timeouts、async hangs、またはデバッグ出力を診断する | references/common-errors.md | 推測なしのエラー対応 マッピング |
| Flutter plugin packages、native Android/iOS コード、example-app integration テスト、または plugin registration/error paths をテストする | references/plugin-testing.md | Plugin package レイアウトおよび native/Dart テスト分割 |
| このスキル、リファレンス、またはサンプルを編集する | scripts/verify-examples.sh | 古いパターンと壊れたリンクの決定的なスモーク チェック |
必須検証
- Dart テストまたは本番コードを編集した後、最初に最も狭い関連コマンドを実行してください。例：
flutter test test/my_widget_test.dart、flutter test --plain-name "subtree"、または純粋な Dart packages の場合はdart test。 - 生成された Mockito mocks を追加または変更した後、テストを実行する前に
dart run build_runner buildまたはリポジトリの確立されたビルド コマンドを実行してください。 - mobile または desktop targets での integration テストの場合、device target が必要な場合は
flutter test -d <device-id> integration_test/<test_file>.dartを実行してください。それ以外の場合はドキュメントに記載されているプロジェクト コマンドを実行してください。 integrationDriverを必要とする browser integration テストの場合は、flutter drive --driver=test_driver/integration_test.dart --target=integration_test/<test_file>.dart -d chromeまたはプロジェクトの web driver コマンドを実行してください。- 不安定なテストを修正した後、特定のテストを複数回実行するか、リポジトリの repeat/randomization オプション（存在する場合）を使用してください。
- このスキルまたはそのリファレンスを編集した後、
bash flutter-testing/scripts/verify-examples.shを実行してください。
制約
- Widget および integration テストには
package:flutter_test/flutter_test.dartを使用し、Flutter bindings が不要な純粋な Dart テストにのみpackage:test/test.dartを使用してください。 - ユーザーに見える動作と公開 contracts をテストしてください。パフォーマンス作業により明示的に必要とされない限り、private メソッド呼び出し、widget インターナル、または偶発的な rebuild 数を assert しないでください。
- 実際のネットワーク、実際のストレージ、timers、permissions、または OS ダイアログの代わりに、依存性注入、fake repositories、fake platform interfaces、または MethodChannel handlers を使用してください。
- async の不確実性を隠すために固定された
Future.delayedwaits を使用しないでください。決定的な fakes、明示的な pumps、pumpAndSettle（animations が settle できる場合のみ）、または bounded カスタム pumps を使用してください。 - 古いコマンドまたは API を使用しないでください：
--no-sound-null-safety、flutter test --platform ...、tester.trace、tester.takeScreenshot、captureNamed、またはflutter pub run build_runner build。 - テスト サーフェス サイズを変更するか、隠された state を使用してアプリを再度 pump することで、connectivity、permissions、または persistence をシミュレートしないでください。明示的な fakes、test hooks、または実際の integration targets を使用してください。
フォールバック
リポジトリにテスト レイヤを選択するのに十分なコンテキストがない場合は、target 動作と優先 test レベルを尋ねてください。デバイス、browsers、native tooling、ネットワーク アクセス、コード生成、または依存性ダウンロードが検証をブロックしている場合は、失敗した正確なコマンド、検証されなかったもの、およびユーザー向けのリスクで完了してください。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- madteacher
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/madteacher/mad-agents-skills / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理（非同期ジェネレータを含む）、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。