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 (≥2 separate characteristic tests)

1. functional/test_create_message.py::test_create_message_roundtrip — §4.3 create-an-object + read-it-back: first user (system admin) → login → create team → create channel → POST a unique marker message → GET it back by id → assert the text round-trips.
2. functional/test_multiuser_message.py::test_second_user_reads_first_users_message — the defining team-chat behaviour (distinct code path: membership + ACL + cross-user delivery): user_a posts a unique marker; a SECOND user (created via admin API, added to team+channel) logs in with its own session and GETs the channel posts → asserts it sees user_a's message. Not a self read-back.

• functional/test_health_check.py — test_root_serves (/ 200/302) + test_system_ping_ok (/api/v4/system/ping → {"status":"OK"}, API liveness). Supporting health/liveness, not counted toward the P3 ≥2 floor.

P4 — Backup data-integrity (real)

ops.py seeds a postgres ci_marker row (psql in the postgres service); test_backup.py asserts it at backup time, test_restore.py asserts it survives restore, test_upgrade.py asserts it survives the upgrade. Requires recipe-PR recipe-maintainers/mattermost-lts#1: the published recipe dumped the DB on backup but shipped NO backupbot.restore.post-hook and archived the whole live PGDATA dir, so a restore extracted files under the running postgres without reloading them → the DB silently kept the un-restored state (test_restore_returns_state RED). The PR switches to the coop-cloud /pg_backup.sh convention (dump-only backup + terminate/FORCE-drop/recreate/reimport restore); with it the ci_marker survives backup→restore. See DECISIONS.md "mattermost-lts postgres restore recipe-PR".