flutter-device-testing
Flutter Device Testing
Use the smallest target matrix that proves the changed behavior, then state what was and was not exercised. Identify the runtime target separately from the data source used by the flow.
Discover before acting
Inspect the project's SDK, supported platforms, flavors, entrypoints, and existing test tooling. Run flutter devices and, when a virtual target must be started, flutter emulators. Resolve one target by stable identifier, record whether it is reused or task-created, and wait until it is ready. Do not erase, reset, recreate, uninstall from, or clear data on a user's target without explicit need and authorization.
Prefer Flutter CLI and available Dart and Flutter MCP capabilities for Flutter-owned state. Use adb or simctl only for platform control they actually provide. Flutter finders cannot operate native system UI such as permission dialogs, notification trays, or platform views; use a native-capable harness already adopted by the project when that interaction is required. Do not introduce Patrol, Maestro, Appium, or another framework merely because it is familiar.
Workflow
- Confirm dependencies and generated code are ready without changing the project's package or architecture choices.
- Verify target readiness and the flavor-specific application identity before changing runtime state.
- Launch with the correct flavor, entrypoint, defines, and build mode; never place credentials in command arguments or retained artifacts.
- Exercise the exact user flow and relevant lifecycle or platform states. Distinguish state injection from observing the real prompt, provider, or OS delivery path.
- Capture focused assertions, screenshots, and filtered logs that correspond to the tested build. Run the project's integration or native-UI harness when durable automation is required.
- Restore task-created target overrides and remove only task-owned artifacts, including after failures.