Add an automated smoke E2E test for the app's critical path

morten-olsen commented

2026-09-17 13:07:49 +02:00

Owner

Every change to the composition root, the engine or the persistence
adapters currently ends with a hand-driven emulator smoke: install,
launch, grant permissions by hand, tap the demo workflow, check the
snackbar, check the Activity tab. It caught nothing this time, but it is
the only thing standing between a green task ci:quality and an app that
does not start — and it is not repeatable by anyone but the person who
remembers the steps.

Why now

The phase 7 improve pass moved AutomationGraph to a single instance on
MacrosApplication and routed 13 construction sites through a Context
accessor. Nothing in the JVM gate can see that the app still boots, and
app/src/androidTest covers capabilities rather than the app's own
startup path — there is no test that launches MainActivity at all.

Scope

An instrumented test that exercises the path a user takes on a cold
start, asserting on app state rather than pixels:

Launch MainActivity from a cold process.
The seeded demo workflow is listed — this is the repository, the
codec and the action registry all resolving.
Run it, and assert the run reaches Succeeded in SqliteRunJournal
via history(), not just that a snackbar appeared.
Publish the local test signal broadcast and assert a second run is
recorded — this is the receiver -> automationGraph -> EventGateway
path that every platform trigger shares.
Assert exactly one AutomationGraph was constructed for the process.

Compose UI testing is not set up in this repo; step 2 and 3 may be
cheaper to drive through MacrosViewModel plus the authoring surface
than through the UI tree. Decide that when implementing — the value is
in the assertions, not in tapping.

Notes

Permission grants must be part of the test setup (GrantPermissionRule
or pm grant in the runner), otherwise it hangs behind a dialog the
way the manual smoke does.
connectedDebugAndroidTest uninstalls the app afterwards, so anything
depending on retained app data has to seed it itself.
These stay outside task ci:quality (they need an emulator). Worth
deciding separately whether CI should gain an emulator stage, or
whether this runs on a release-tag workflow only.

Every change to the composition root, the engine or the persistence adapters currently ends with a hand-driven emulator smoke: install, launch, grant permissions by hand, tap the demo workflow, check the snackbar, check the Activity tab. It caught nothing this time, but it is the only thing standing between a green `task ci:quality` and an app that does not start — and it is not repeatable by anyone but the person who remembers the steps. ## Why now The phase 7 improve pass moved `AutomationGraph` to a single instance on `MacrosApplication` and routed 13 construction sites through a `Context` accessor. Nothing in the JVM gate can see that the app still boots, and `app/src/androidTest` covers capabilities rather than the app's own startup path — there is no test that launches `MainActivity` at all. ## Scope An instrumented test that exercises the path a user takes on a cold start, asserting on app state rather than pixels: 1. Launch `MainActivity` from a cold process. 2. The seeded demo workflow is listed — this is the repository, the codec and the action registry all resolving. 3. Run it, and assert the run reaches `Succeeded` in `SqliteRunJournal` via `history()`, not just that a snackbar appeared. 4. Publish the local test signal broadcast and assert a second run is recorded — this is the receiver -> `automationGraph` -> `EventGateway` path that every platform trigger shares. 5. Assert exactly one `AutomationGraph` was constructed for the process. Compose UI testing is not set up in this repo; step 2 and 3 may be cheaper to drive through `MacrosViewModel` plus the authoring surface than through the UI tree. Decide that when implementing — the value is in the assertions, not in tapping. ## Notes - Permission grants must be part of the test setup (`GrantPermissionRule` or `pm grant` in the runner), otherwise it hangs behind a dialog the way the manual smoke does. - `connectedDebugAndroidTest` uninstalls the app afterwards, so anything depending on retained app data has to seed it itself. - These stay outside `task ci:quality` (they need an emulator). Worth deciding separately whether CI should gain an emulator stage, or whether this runs on a release-tag workflow only.

morten-olsen added the

feature

label

2026-09-17 13:07:49 +02:00

morten-olsen referenced this issue

2026-09-17 13:12:51 +02:00

Deepening pass: six improve-phase changes #33

Rows
Columns

Add an automated smoke E2E test for the app's critical path #32

Why now

Scope

Notes