How to use AI to write useful tests
Turn a behavior change into focused Django, node:test or Playwright coverage with disposable data.
Replace bracketed values before sending the prompt. Give the assistant the relevant public files from the exact target release; use synthetic examples and keep credentials, private campaigns and proprietary material out of its context.
What you will build
Protect an actual boundary, such as rejecting another campaign’s resource or avoiding duplicate effects on retry. Select the smallest test layer that can observe that behavior.
Context to give the assistant
docs/en/testing.md: actual commands, explicit test database and browser fixture isolation.
The changed service/controller and neighboring tests, plus a clear expected outcome.
The project’s current tools: Django/unittest, node:test and standalone Playwright scripts.
Step by step
Write the intended behavior and an example failure before generating assertions.
Ask the assistant to choose service, pure JavaScript or real-browser coverage with a reason.
Allocate independent database, media, module state, ports and outputs.
Run the focused test; broaden only when a new failure or unresolved concern warrants it.
Copy and adapt this prompt
Repository: [local checkout or public repository]
Target host release: [installed/requested version; preserve it]
Task scope and authorization: [what may be changed/published]
Add meaningful regression coverage for [behavior] in [owning domain].
Read docs/en/testing.md and the existing neighboring fixtures. Use Django/unittest, node:test or the documented Playwright harness; do not invent a root npm test or pytest runner.
Isolate data, media, packages, ports and outputs without editing the real .env. Changing GRAVEWRIGHT_DATABASE alone does not relocate the explicitly configured Django test database.
Cover the real boundary: [authorized/denied caller, retry with the same operation UUID, conflict refresh, or visible rendering outcome]. Give each new logical operation a fresh UUID.
Avoid tests that merely repeat implementation constants or documentation. Preserve assertions and report why the test would fail without the fix.
Run the narrowest relevant command and report actual results. Treat source-only checks as insufficient when the change requires native/browser execution.
Inspect the actual files and supported APIs before proposing code. Do not invent commands, fields, endpoints or package capabilities.
Use disposable test data and installation-local tools/caches. Explain any unsupported requirement and validate the result with the project’s real tools.
Deliver concrete files or editor steps, the checks performed and any unresolved limits.How to validate
Review fixture isolation before running any command that can replace a test database.
Check that assertions observe behavior at the actual boundary.
Record the focused command and result; preserve logs in disposable local output.
Ready when
A focused test can detect the original regression, uses isolated state and passes with the intended implementation.
Continue with the module reference, public API and testing guide.