feature-tester

name

feature-tester

description

Exercise an EXISTING feature or flow end-to-end and report whether it actually works — the "vaan testaa" / AI-QA skill. Drives real behavior (DB/RLS, RPC, edge function, or browser UI) with real roles and payloads, then reports pass/fail with evidence. Writes NO test files and cleans up any test data. Use for: "testaa tämä ominaisuus/flow", "aja X läpi", "toimiiko X oikeasti", "AI-testaa", "verify this feature works", "does anon see X", checking an approval/visibility flow, validating a flow before a human tester, confirming a bug fix behaves correctly at runtime. NOT for: writing test files (→ test-writer), fixing red CI (→ ci-doctor), auditing security posture/access matrices (→ security-auditor), root-causing a known bug (→ systematic-debugging). Triggers: "testaa ominaisuus", "vaan testaa", "aja läpi", "toimiiko", "AI-testaa", "ai-testattu", "feature test", "does it work", "näkyykö anonille", "hyväksyntävirta toimii".

Feature Tester

Prove whether a shipped feature works right now, by exercising it — not by reading code and reasoning, and not by writing test files. The deliverable is a pass/fail report with evidence, plus any bug found while exercising it.

The one rule that makes a test faithful

Test at the LOWEST layer that the real user actually goes through — but first confirm what that layer IS. A test that probes a different path than the app uses will pass while the feature is broken (or vice-versa).

Before writing any probe, answer: how does the real client read/write this?

• Direct table select under RLS? → test the table with the real role (see references/rls-role-test.md).
• SECURITY DEFINER RPC? → call the RPC as the real role; table RLS is NOT the story (see references/rpc-edge-smoke.md).
• Edge function? → invoke it with a real JWT and real payload.
• UI-only behavior (rendering, keyboard, audio sync)? → drive the browser (see references/browser-flow.md).

Grep the hook/component for the actual call before choosing. Example lesson: the community-answer public read is a direct answers table select (usePublishedAnswers), so its anon visibility is pure table RLS — testing an RPC instead would have missed the bug entirely.

The golden rule: never leave test data in production

This skill runs against the live Supabase project. Every fixture MUST be undone. In order of preference:

1. Rolled-back transaction — do the whole test inside BEGIN … ROLLBACK. For DB/RLS tests, wrap the assertions in a DO $$ … $$ block that RAISE EXCEPTION 'ALL PASS >> …' at the end: any failed assertion raises with which check failed; success raises the summary. Either way the exception rolls back ALL fixtures atomically. This is the primary pattern — see references/rls-role-test.md.
2. Create + explicit cleanup — when a rollback can't hold (e.g. an edge function commits, or a browser flow writes). Mark rows unmistakably (body_md prefix ZZ_TEST_, a known test user), and DELETE them at the end. Re-query to confirm zero test rows remain. Report exactly what was created and removed.
3. Read-only probing — best of all: if data already exists in the needed state, just observe it (no writes). Survey with a privileged SELECT first.

Never mutate a real user's settings/rows outside a transaction that restores them. If a cleanup could be interrupted, capture the original value first and restore it explicitly.

Workflow

1. Restate the flow as concrete pass/fail checks. Turn "the approval flow works" into ordered assertions with expected outcomes (C1 hidden before approval, C2 visible after, C3 hidden without opt-in, C4 author sees own).
2. Find the real path (grep the client call) → pick the layer.
3. Survey live state (privileged SELECT) → reuse existing rows read-only where possible; otherwise plan minimal fixtures + cleanup.
4. Exercise each check as the real role/identity (recipes in references).
5. Report: a table of check → expected → actual → pass/fail, the evidence (counts, responses, screenshots), confirmation that all test data is gone, and any bug found (with root cause + suggested fix). If a fix is applied, re-run the whole suite to confirm green.

Choosing the layer — recipes

Layer	Use when	Recipe
DB / RLS	visibility, ownership, per-role access, approval gates	references/rls-role-test.md
RPC / edge fn	server logic, SECURITY DEFINER reads, quota/validation	references/rpc-edge-smoke.md
Browser UI	rendering, navigation, keyboard/audio/cinema, "feels right"	references/browser-flow.md

Prefer the lowest faithful layer (it's fastest and most deterministic); escalate to the browser only when the behavior lives in the UI or when a human would only trust an on-screen result.

Boundaries (hand off)

• Need a regression test committed to the repo → test-writer.
• The exercise reveals a red CI / build failure → ci-doctor.
• The question is "is this access control safe/complete" (matrix, GRANTs, advisors) rather than "does this flow work" → security-auditor.
• Found a bug and need to root-cause it methodically → systematic-debugging.
• Fixing what you found is fine here; if the fix is a migration/RPC change, use the relevant domain skill's conventions (e.g. supabase-migration-writer).

Learnings

Read references/learnings.md before probing — it holds gotchas (rollback-vs-result, role-impersonation, faithful-path) discovered while running these tests.