A negative test is not a random string thrown at an endpoint. It is a specific claim about what the API must reject, preserve, or explain.
Why this Skill is needed
API Negative Testing designs failure cases from contract rules, boundaries, authorization, state transitions, and dependency behavior.
What the Skill does
Extract field types, required/null rules, ranges, length and size constraints, identity/permission rules, error contracts, and dependency behavior. Turn them into ANT-## candidates with preconditions, behavior of concern, source evidence, validation, impact/priority, owner role, and close condition.
Keep field constraints and authorization rules traceable separately. When a rule is missing, conflicting, or not applicable, leave the case open instead of inventing an expected response. Candidate counts do not prove coverage, and the Skill does not execute tests.
Awesome QA Skills organizes Skills by language and testing stage; the series overview explains the shared installation model.
What it does not do
It does not replace a complete strategy, supply missing API behavior, or decide which status code should be used. It also does not infer that rejection caused no side effect: records, events, and partial-success behavior need their own evidence.
What it checks
| Rule family | Candidate variants | Evidence to retain |
|---|---|---|
| Field presence and type | Missing, null, empty, wrong type | Field rule, valid neighboring control, response and state |
| Numeric or string limits | Below, at, and above the sourced boundary; encoding and size | Constraint source, exact variant, response |
| Identity and permission | Wrong principal, missing permission, forbidden object | Authorization source, identity context, allowed/rejected result |
| State transition | Request from an ineligible or terminal state | State rule, starting state, resulting state |
| Dependency and rate limit | Supplied failure or limit condition | Failure policy, retry meaning, durable effects |
For independent rules, vary one factor at a time. Combine invalid factors only when their interaction is itself a risk; record which rule each factor exercises. Include a valid near-neighbor to distinguish over-rejection from correct rejection.
Audit inputs before you start
Before analyzing Negative case, classify the input into six evidence states. A gap is not automatically a failure, but it must not disappear inside the conclusion.
| State | Meaning | How this Skill should handle it |
|---|---|---|
| known | Directly supported by the supplied material | Keep the source, version, and time with the judgment |
| missing | Needed for this pass but not supplied | Name the smallest evidence action and limit the conclusion |
| conflicting | Sources disagree | Show both sources and route the conflict to an owner |
| stale | Present but outside the relevant version or time window | Mark freshness; old evidence is not current proof |
| out_of_scope | Related but excluded from this pass | Keep the boundary explicit |
| assumptions | Temporarily adopted to continue analysis | State how and when the assumption will be checked |
Keep the input version, scope, environment, evidence locations, and accountable owner together. Without a run record, deliver analysis, design, or a validation plan—not an execution pass.
From problem to structured Finding
ANT-## finding contract
Each candidate should name the constraint or permission rule, input variant, preconditions, allowed/rejected expectation, response and side-effect observation, source evidence, evidence state, impact/priority, owner role, close condition, and validation. Keep field and permission rules separately traceable; do not merge distinct invalid classes into one result.
A complete case
This case follows Input, Analysis, Finding, Decision, and Validation. When material is incomplete, keep missing, conflicting, or assumptions visible instead of turning them into a pass.
Input
| Material | What to provide | What to do when it is missing |
|---|---|---|
| Contract rules | Required fields, formats, limits, enum values, and state transitions | List rules before generating cases |
| Invalid partitions | One invalid factor at a time, paired invalid factors, and malformed payloads | Keep the reason for rejection visible |
| Safety evidence | Status, error body, persisted records, and downstream events | Reject without mutation must be proved |
Use a request like this:
Use the api-negative-testing Skill.
Task: challenge a bulk-import API with malformed rows, oversized batches, duplicate records, and an invalid state transition
Inputs: [requirements, versions, links, logs, reports, or data paths]
Scope: [included and excluded objects]
Unknowns: [missing environment, accounts, data, or permissions]
Expected output: [risk-ordered findings, evidence status, and next actions]
Audit the inputs first. Separate facts, assumptions, and open questions. Do not claim execution without a run record.
Analysis
Start with a bounded pass—challenge a bulk-import API with malformed rows, oversized batches, duplicate records, and an invalid state transition. For an import row, test an unknown currency, a negative amount, a duplicate external ID, and a row that updates a closed account. Assert both the error contract and that no valid row was partially committed unless the API explicitly promises partial success.
The useful handoff keeps the input version, time window, evidence index, owner, and next validation action together. The Skill can organize uncertainty; it cannot manufacture the missing artifact.
Finding
The following is a recording pattern, not an execution result:
| Field | Example |
|---|---|
| ID and subject | ANT-01 — closed-account update in the bulk-import operation |
| Preconditions and concern | Account is closed; the sourced state rule may prohibit the update |
| Evidence state | UNASSESSED until the applicable rule, response, and persisted-state query are available |
| Impact/priority and owner | Explain the affected record or downstream effect; name the API/data owner; score only with the project scale |
| Close condition and validation | Verify allowed/rejected result, row-level persistence, and event ledger with a repeatable isolated check |
Decision
The API or domain owner confirms whether the state and field rules apply. If the import contract does not say whether rows may partially succeed, keep that transaction decision open rather than assuming an all-or-nothing write.
Validation
Use an isolated environment and approved safe data. Compare the response with the applicable rule, then query the affected records and downstream events; a rejection status alone cannot establish that no mutation occurred.
How a Finding enters the next stage
Handoff output
| Output field | Why it exists | Example status |
|---|---|---|
| Negative case | Invalid condition and expected rejection | Traceable rule |
| Response judgment | Status, code, safe message, and retryability | Client action |
| Mutation check | Records or events that must not change | State evidence |
Do not write “passed” without a run record, query result, or source artifact. A good negative suite is partitioned, not theatrical. It finds the smallest input that violates one rule, then adds combinations only where the interaction itself creates risk.
Next-stage route
Send the constraint-to-variant table, valid controls, response expectations, and state-mutation checks to the executor. Keep candidate design separate from executed results and from unresolved transaction policy.
How to prepare better input
Provide the versioned schema, field rules, authorization model, error contract, rate-limit or dependency policy, and evidence about affected records and events. State whether partial success is allowed; if unknown, preserve it as a contract gap.
Working with other Skills
- API Error Contract Testing:deepens failure response assertions.
- Boundary Value Testing:systematizes limit selection.
- API Security Testing:covers forbidden access and leakage.
Common traps
- Generating invalid data without mapping it to a rule.
- Asserting rejection but ignoring partial writes.
- Using only one malformed payload for every failure class.
Install and invoke
Install the individual Skill. The series overview carries the longer installation explanation.
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/api-negative-testing -g
After installation, invoke it with the api-negative-testing Skill and attach the real project material.
FAQ
Should negative tests run against production?
Use an isolated environment or approved safe data; the case design does not authorize destructive requests.
How many invalid combinations are enough?
Enough to cover independent rules and high-risk interactions; prioritize by impact, not by combinatorial volume.
The example above is a design and review pattern, not an execution result. Keep static analysis, runtime evidence, human approval, and release acceptance separate.
References
Source Skill and execution contract
The complete execution contract lives in the API Negative Testing prompt. Read it before invoking the Skill; the prompt defines the detailed workflow and output contract. The source directory also contains the entry point and supporting assets where they exist.
The entry point centers invalid shape, boundary values, forbidden state, authorization, dependency failure, and safe response. Read the supporting prompt before writing a conclusion, and keep the Skill’s decision boundary visible.
Reference links
-
API Negative Testing:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/api-negative-testing/prompts/api-negative-testing.md
-
Awesome QA Skills: API Negative Testing source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/api-negative-testing
-
Awesome QA Skills GitHub:https://github.com/naodeng/awesome-qa-skills
-
API Negative Testing details:https://inaodeng.com/en/qaskills/api-negative-testing/