What this prompt does
This prompt creates a comprehensive testing strategy for your [framework] cross-platform app, organized around a testing pyramid. It sets unit coverage at [unit_coverage]% and widget coverage at [widget_coverage]%, then layers integration and E2E tests on top. It specifies unit setup with [test_framework], widget tests for [critical_screens], integration tests for [integration_points], E2E tests with [e2e_tool] across a [device_matrix], an API-mocking strategy, snapshot tests for UI regression, performance tests, accessibility tests, and a CI pipeline on [ci_platform] running both simulators and real devices. It also covers test-data management, flaky-test handling, and a device cloud via [device_farm].
The structure works because a sane pyramid is what lets you ship updates without a manual regression marathon. Fast unit tests catch logic errors cheaply, widget and integration tests around [critical_screens] and [integration_points] catch the breakages that actually cost money, and a small layer of E2E tests on real devices catches what simulators never show. Planning for flaky tests and a [device_farm] up front keeps the suite trustworthy as it grows.
When to use it
- You're shipping a
[framework]app and want to release without manual regression every time. - You have critical flows (login, checkout, sync) that must not break silently.
- You need integration coverage over
[integration_points]like the API, local DB, and deep links. - You want E2E tests running on a real
[device_matrix], not just simulators. - Flaky tests are eroding trust in your CI and you need a handling strategy.
- You're setting coverage targets and want them structured as a pyramid, not a flat number.
Example output
Expect a testing plan: coverage targets for each layer, [test_framework] setup for unit tests, widget tests for [critical_screens], integration tests for [integration_points], E2E flows in [e2e_tool] mapped to the [device_matrix], an API-mocking approach, snapshot and accessibility tests, and a [ci_platform] pipeline that runs on simulators and on [device_farm] real devices. Flaky-test handling and test-data management are addressed so the suite stays reliable.
Pro tips
- Set
[unit_coverage]and[widget_coverage]as honest targets; chasing 100% on UI code wastes effort better spent on integration tests around real flows. - Prioritize
[critical_screens]and[integration_points]— login, checkout, and sync earn far more test investment than rarely-used settings screens. - Mock the API consistently so tests are deterministic; flaky network calls are a top source of false failures.
- Run E2E on the full
[device_matrix]sparingly — it's slow and costly, so reserve it for the few flows where device differences genuinely matter. - Budget for flaky-test handling from the start, since a suite people don't trust gets ignored, defeating the point.
- Use
[device_farm]for the long tail of real devices, because hardware-specific bugs rarely reproduce on a simulator.
