Test Assertion Patterns
Overview
This page defines assertion standards for Bruno API tests. The goal is to eliminate false-pass tests, add meaningful response validation, and keep error-path behavior explicit.
False-Pass Patterns
Skip on Non-200
Do not guard all assertions behind a success status. Always assert the expected status directly.
Overly Broad Status Checks
Avoid accepting broad ranges or mixed success/error status lists for a happy path. Assert the exact expected code.
No Body Validation
Every happy-path request should assert both the status code and at least one meaningful response property.
Wrong Expected Code
Match the endpoint contract. Creation endpoints may return 201; validation failures may return 400 or 422.
Minimum Assertion Standard
Every request should include:
- exact status assertion
- JSON/content-type assertion when the endpoint returns JSON
- response-shape assertion for happy paths
- error-code or message assertion for error paths
Gap Categories
| Category | Priority | Description |
|---|---|---|
FALSE_PASS | Critical | Test accepts a failure as success |
WRONG_STATUS_CODE | Critical | Test checks the wrong specific code |
NO_ERROR_SCENARIOS | High | Endpoint lacks invalid-input coverage |
NO_TESTS | High | Request has no assertions |
HAPPY_PATH_ONLY | Medium | Only checks success status |
NO_BODY_VALIDATION | Medium | Checks status but not response shape |
NO_CONTENT_TYPE | Low | Missing content-type assertion |
Editing Rules
- Keep request files valid
.brusyntax. - Preserve existing passing coverage unless the endpoint contract changed.
- Prefer focused request files over large multi-purpose scripts.
- Run the smallest relevant Bruno folder after edits.