The drift between emulator and device
Test a native app and you maintain a harness per platform, then discover the emulator behaved differently from the phone. Coverage gaps hide in the difference between passed on my machine and passed on the user's. Every platform multiplies the surface you must re-verify by hand.
A mini-program runtime narrows that surface: the same program runs on iOS, Android, and the developer emulator through one runtime contract, so a single automated suite exercises all three.
What mini-program testing is
The runtime ships with automation APIs and a headless mode: WeChat provides the miniprogram-automator and DevTools, Alipay ships Minitest, and both let a script drive pages, tap elements, and assert state without a human tapping a screen. Because the runtime is the common layer, one test project targets every host. GitLab CI and GitHub Actions then run that suite on every commit.
Where the gap shows up
| Step | Native (per-platform) | Mini-program runtime (one suite) |
|---|---|---|
| Test harness | One per OS | One source |
| Emulator vs device | Drifts | Same runtime |
| Coverage | Hand-reconciled | Single run |
| CI integration | Per platform | One pipeline |
| Regression cost | Multiplied | Flat |
The result is one green check that means the same thing on every device.
Why one suite beats three
A single suite means a regression is caught once, in the same environment, instead of surfacing as a platform-specific surprise. It also means new hosts reuse the existing tests rather than spawning a new harness, so coverage grows with the ecosystem, not against it.
How Cross Mini App applies it
Cross Mini App runs programs on a runtime that exposes automation hooks across iOS, Android, and the emulator, so a single CI suite covers every surface. You write one test, run it everywhere, and ship when the check is green on all of them. You stop reconciling emulator and device and start trusting one result.
That is the difference between three harnesses that drift and one suite that holds.
