G5 · Negative Test Sets: Negative test sets are F4/F6's schema-DERIVED checklist BROUGHT TO LIFE in Postman: every `required`/`type`/`enum` violation is now a SEPARATE request in
Negative test sets are F4/F6's schema-DERIVED checklist BROUGHT TO LIFE in Postman: every `required`/`type`/`enum` violation is now a SEPARATE request in a Postman folder. The Java equivalent is writing a SEPARATE `@Test` for every invalid input combination of a method (even with `@ParameterizedTest`). So why keep these as SEPARATE requests instead of merging them into one? Because every negative scenario should produce SEPARATE evidence — when one fails, it should not stay unclear WHICH one failed; a merged request says "something is wrong", separate requests say "EXACTLY this rule was violated". **For deep negative test design → see the `/postman` page.**
🎬 From a Schema Constraint to a Postman Folder
F6: schema checklist
"Negative Tests" folder
Separate evidence per violation
We have the checklist derived from the schema in F6: missing title, out-of-enum severity, invalid email...
Each checklist item becomes a SEPARATE request/folder item in Postman — the "Negative Tests" folder is born.
After the run it becomes clear which rule violation the server ERRORS on, and which it SILENTLY ACCEPTS.
From Schema to Negative Test Folder
Use the negative scenario list derived from the schema in F6.
Each item becomes a request…
Create a separate Postman request for each violation, write the relevant pm.test.
Compare the results…
See which rule is really enforced, and which silently passes.