Files
cc-ci/tests/uptime-kuma/PARITY.md
autonomic-bot 44e02425ab
Some checks failed
continuous-integration/drone/push Build is failing
feat(cfold): canonicalize custom test layout
2026-06-12 16:08:18 +00:00

41 lines
3.3 KiB
Markdown

# Parity — uptime-kuma
The recipe-maintainer corpus has **no** `recipe-info/uptime-kuma/tests/` directory — uptime-kuma
was not yet in the recipe-maintainer parity suite. So this PARITY.md documents the Phase-2
recipe-specific tests + the Phase-2 health_check as the parity-aligned baseline.
## Recipe-specific tests (Phase-2 P3, ≥2 beyond parity)
uptime-kuma is a **real-time monitoring app** with a Socket.IO real-time channel. Its defining
behaviors:
- The SPA bundle is served at `/` with uptime-kuma branding.
- Real-time updates use Socket.IO at `/socket.io/`.
- (Plan §4.3 prescribed test: create a monitor + list it. Deferred to Q4 follow-up — requires
completing the initial setup flow via Socket.IO emit then logging in to obtain a session
token; substantial work that adds Socket.IO client to the harness. The current tests
exercise the same Socket.IO subsystem + SPA bundle the create-monitor flow would use.)
| cc-ci file | what's verified | rationale |
|---|---|---|
| `tests/uptime-kuma/custom/test_socketio_handshake.py` | GETs `/socket.io/?EIO=4&transport=polling` → 200 + Engine.IO `open` packet (body starts with `0{`, parses as JSON with `sid` and `pingInterval`). | Proves the **real-time backend is wired** through the nginx proxy. Non-vacuous: a wedged Socket.IO returns 404/502 here; a misrouted nginx returns 404. Only a correctly-wired uptime-kuma + Engine.IO listener completes the handshake. |
| `tests/uptime-kuma/custom/test_spa_branding.py` | GETs `/`; asserts the HTML body contains the uptime-kuma brand string AND references one of the SPA's bundled asset paths (`/assets/`, `/icon.svg`, `favicon`, `main.`). | Distinguishes "the uptime-kuma SPA is bound" from "nginx is serving a placeholder/blank 200." Non-vacuous: a wedged backend's fallback page contains none of these markers. |
| `tests/uptime-kuma/custom/test_monitor_wizard.py` | Playwright browser test: completes the first-run setup wizard (admin create), creates an HTTP monitor targeting the app's own root URL, waits ≤90 s for the monitor to report **Up** with a real heartbeat timestamp, then creates a second monitor on a dead port and asserts **Down**. | §4.3 prescribed test — proves uptime-kuma's actual monitoring function (wizard + probe engine), not just that the SPA renders. Non-vacuous: Up requires a real outbound HTTP probe to succeed; Down requires the probe to detect connection-refused. Status is driven by Socket.IO heartbeat events from the server, not echoed from config. Green in drone build #460 (LEVEL 5). Phase kuma, 2026-06-11. |
## Backup data-integrity (P4)
The base recipe stores state in a sqlite volume; backup-capable detection is automatic
(Phase-1d auto-scan of compose.yml `backupbot.backup` labels). When deployed with
`compose.mariadb.yml`, the DB volume + sqlite both back up via the recipe's `pg_backup`
mechanism. Lifecycle overlays not yet authored — Q5 catch-up if backup data-integrity proves
needed for this recipe.
## Playwright (P6)
Not yet authored. uptime-kuma's UI is a Vue SPA; a Playwright flow would exercise the
setup wizard + monitor creation. Q4 follow-up.
## Deferred
See `machine-docs/DEFERRED.md` — entry "2026-05-28 — uptime-kuma create-a-monitor (§4.3
prescribed)" (re-entry: --extra-tests flag OR another Socket.IO-needing recipe enrollment).