← ClaudeAtlas

write-db-testlisted

Use when adding a Playwright test that queries a database directly — verifying persistence, migrations, or that a write through the app landed correctly. Covers parameterised statements only, ordering for shared-row tests, teardown that survives failure, and keeping connection details out of the spec. Reads conventions from .claude/test-profile.md.
AndreiBanu1/playwright-suite-skills · ★ 1 · Testing & QA · score 72
Install: claude install-skill AndreiBanu1/playwright-suite-skills
# Skill: write-db-test Add one spec that talks to a database. First, a question worth asking out loud: is a database test the right instrument here? These specs couple to schema rather than behaviour, so they break on refactors that changed nothing a user can see. They earn their keep for persistence that has no API surface, for migration verification, and for asserting that a write made *through* the product actually landed. For anything observable through an endpoint, a request spec is cheaper and more stable. If this is the second kind, say so before writing it. ## Preconditions 1. `.claude/test-profile.md` exists and lists a `database` group. If it does not, this repo may have no database access wired at all — ask before adding the first one, because connection handling and credential storage are decisions the user owns. 2. You know which table or entity, in which environment, and whether the spec writes. ## Procedure ### 1. Read the existing database specs Record the verbatim import line, how a query is issued, what the query helper returns (a driver result object, an array of rows, something custom), how connection details reach it, and how existing specs handle cleanup. ### 2. Write the spec ``` <the profile's verbatim database import line> // entity and seed values as module-level constants, not scattered literals test('<what should be true of the stored data>', async ({ <fixtures from the profile> }) => { // act — the query, always parameterised