cc-ci/tests/mattermost-lts/PARITY.md

mattermost-lts — parity & coverage map (Phase 2)

P2 — Parity port

No recipe-maintainer corpus exists for mattermost-lts (/srv/recipe-maintainer/recipe-info/ has no mattermost-lts/ entry). P2 (parity) is therefore vacuously satisfied — there are no recipe-info/mattermost-lts/tests/*.py scripts to port. Coverage is delivered entirely via the generic lifecycle tiers (install/upgrade/backup/restore) + the recipe-specific functional tests below.

Lifecycle (generic tiers — Phase 1d/1e)

mattermost-lts ships no test_<op>.py overlays, so the generic install/upgrade/backup/restore tiers run by default (the Phase-1e invariant: no overlay ⇒ generic runs). The stack bundles its own postgres in-compose (no external dep), so no dependency resolution is needed.

P3 — Recipe-specific functional tests

• functional/test_health_check.py
  • test_root_serves — web app served at / (200/302).
  • test_system_ping_ok — GET /api/v4/system/ping → {"status":"OK"} (proves the mattermost server + API router are live, not a Traefik fallback).
• functional/test_create_message.py — §4.3 prescribed create-an-object + read-it-back (planned, authored against the live instance): create the first user (system admin) → login → create team → create channel → POST a message → GET it back → assert the message text round-trips. (In progress — requires response-header access for the mattermost login Token; harness.http extension pending.)

P4 — Backup data-integrity

Planned ops.py: pre_backup seeds an identifiable message via the API; pre_restore mutates/wipes; the restore assertion re-reads the message and asserts it survived (recipe-aware, not health-only). (Follows once the create-message API flow is proven green.)