Follow-up from the discussion in #2188 (comment: #2188 (comment)).
What
An integration_test suite that actually drives example/, presses the pick/save buttons, and asserts the flow completes, running against a real browser/device rather than the headless flutter_test harness.
Why
This repo's CI already proves the example app builds on every platform, but nothing currently exercises it at runtime. A regression that compiles fine but breaks the actual pick/save flow (a bad method channel argument, a broken native callback, and so on) would currently only surface from a user report.
Why this is not the same as the facade constraint smoke test from #2188
That check targets a different failure mode entirely: a compile time mismatch between the platform interface and an implementation, caught by pub downgrade + a real build outside the workspace (example/ can't reproduce that scenario itself, since its dependencies always resolve to the local checkout regardless of downgrade). This issue is about runtime behavior of the current code, not version resolution, so it needs different tooling (integration_test against a real browser/device instead of a build step) and would live in the repo differently (likely under example/integration_test/).
Scope to figure out
- Which platform(s) first, web is the most CI-friendly (an actual browser, no emulator/simulator needed).
- How to interact with a native file picker dialog from an automated test (mocking the platform channel defeats the purpose of testing the real native code; not mocking it means scripting an OS-level file dialog, which is the hard part most plugins struggle to automate).
Follow-up from the discussion in #2188 (comment: #2188 (comment)).
What
An
integration_testsuite that actually drivesexample/, presses the pick/save buttons, and asserts the flow completes, running against a real browser/device rather than the headlessflutter_testharness.Why
This repo's CI already proves the example app builds on every platform, but nothing currently exercises it at runtime. A regression that compiles fine but breaks the actual pick/save flow (a bad method channel argument, a broken native callback, and so on) would currently only surface from a user report.
Why this is not the same as the facade constraint smoke test from #2188
That check targets a different failure mode entirely: a compile time mismatch between the platform interface and an implementation, caught by
pub downgrade+ a real build outside the workspace (example/can't reproduce that scenario itself, since its dependencies always resolve to the local checkout regardless of downgrade). This issue is about runtime behavior of the current code, not version resolution, so it needs different tooling (integration_testagainst a real browser/device instead of a build step) and would live in the repo differently (likely underexample/integration_test/).Scope to figure out