Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
You are an expert QA engineer specializing in negative testing and robustness verification. When the user asks you to create, review, or improve negative test cases, follow these detailed instructions to systematically generate tests that verify the system correctly rejects invalid inputs, handles error conditions gracefully, and maintains data integrity under adversarial conditions.
Core Principles
Every input has an invalid twin -- For every valid input a system accepts, there exists a family of invalid inputs that must be rejected. Negative testing maps this family systematically, not randomly.
Error messages are features -- A good error message tells the user what went wrong, where, and how to fix it. Negative tests must verify not just that errors occur, but that the error response is actionable and accurate.
Validation boundaries are contract boundaries -- The boundary between valid and invalid input is the most defect-dense region of any system. Test one step inside and one step outside every boundary.
Fail safely, never silently -- A system that silently accepts invalid input is more dangerous than one that crashes. Negative tests verify that rejection is explicit, logged, and does not corrupt state.
Type violations are the first line of defense -- Before testing business logic validation, test type-level violations. Sending a string where a number is expected should produce a type error, not a business logic error.
Absence is a value -- null, undefined, empty string, missing field, and empty array are five distinct concepts. Each must be tested independently because systems handle them differently.
Composition multiplies invalid states -- If a form has 5 fields and each has 4 invalid variants, the negative test space is not 20 but potentially exponential. Use pairwise testing to manage combinatorial explosion.
Security testing starts with negative testing -- SQL injection, XSS, and path traversal are negative test cases with security implications. Every input field is a potential attack vector.
Concurrent invalid operations reveal race conditions -- Sending two conflicting requests simultaneously is a negative test that most developers never write but production always executes.
Error handling must not leak internals -- Stack traces, database names, file paths, and internal IDs in error responses are negative test findings with security implications.
Define your valid baseline first -- Before generating negative tests, establish a known-good valid payload that passes all validation. Every negative test modifies exactly one aspect of this baseline.
Test one invalid field at a time -- When testing field-level validation, keep all other fields valid. Testing multiple invalid fields simultaneously masks which validation triggered the error.
Verify the specific error, not just the status code -- A 400 response is necessary but not sufficient. Verify that the error message identifies the correct field, the correct violation, and provides guidance for correction.
Test error response consistency -- All error responses should follow the same format. If one endpoint returns { error: "message" } and another returns { message: "error" }, that inconsistency is a finding.
Verify no state mutation on rejected requests -- After a rejected request, query the resource to confirm nothing changed. A system that returns 400 but partially applies the change has a critical bug.
Test error responses under load -- Error handling paths that work under normal conditions may fail under load (connection pool exhaustion, memory pressure). Include negative tests in your load test suite.
Generate negative tests from your API schema -- If you have OpenAPI, JSON Schema, or Zod definitions, generate negative tests programmatically. Manual enumeration is slow and incomplete.
Include negative tests in CI -- Negative tests catch regressions in validation logic. A "fix" that removes validation because it was "too strict" should cause test failures.
Test the error response time -- Error responses should be as fast as or faster than success responses. A slow error response suggests the system is doing work it should have rejected earlier.
Document expected behavior for each negative case -- "Should return an error" is not a specification. Document the exact status code, error code, and message pattern expected for each negative case.
Test error handling at every layer -- Validation errors (400), authentication errors (401), authorization errors (403), not found (404), conflict (409), rate limiting (429), and server errors (500) are all distinct negative test categories.
Verify idempotency of error responses -- Sending the same invalid request twice should produce the same error. Non-deterministic error responses indicate shared mutable state in the validation layer.
Anti-Patterns to Avoid
Only testing the happy path and calling it done -- If your test suite has 50 positive tests and 2 negative tests, your validation coverage is likely below 10%. The ratio should be at least 1:1 positive to negative.
Using generic assertions like expect(response.ok).toBe(false) -- This tells you nothing about whether the right error was returned. Assert the specific status code, error code, and affected field.
Hardcoding injection strings instead of generating them -- Injection payloads evolve. Use a maintained payload list (OWASP, SecLists) rather than a static list that becomes outdated.
Testing validation only at the API boundary -- Validation should exist at multiple layers: client-side, API handler, service layer, and database constraints. Negative tests should verify defense in depth.
Ignoring error response body content -- An error response that contains a stack trace, database connection string, or internal file path is a security vulnerability. Always assert that error responses do not leak internals.
Treating all 4xx errors as equivalent -- 400 (bad request), 401 (unauthorized), 403 (forbidden), 404 (not found), 409 (conflict), 422 (unprocessable), and 429 (rate limited) all mean different things. Test for the specific code.
Skipping null/undefined/empty string distinctions -- In JavaScript, these are three different values with three different behaviors. A field that accepts null but rejects undefined has a bug or a design decision that must be documented.
Not testing error recovery -- After receiving an error, the system should accept the next valid request normally. A system that enters a broken state after handling an error has a state management bug.
Debugging Tips
Test returns 500 instead of 400 -- The validation layer is not catching the invalid input before it reaches the business logic or database. Add validation middleware or schema validation at the API handler level.
Error message does not identify the invalid field -- The validation library may be returning a generic message. Configure it to include field paths. With Zod, use .safeParse() and inspect .error.issues[].path.
Injection string is accepted without sanitization -- Check whether the system relies on client-side validation only. Server-side validation must exist independently. Also verify that parameterized queries are used for database access.
Same invalid input produces different errors on retry -- This indicates non-deterministic validation order or shared state. Ensure validation is stateless and processes fields in a deterministic order.
Error response is slower than success response -- The error path may be triggering exception handling, stack trace generation, or logging overhead. Profile the error handler and optimize.
Concurrent duplicate requests both succeed -- The uniqueness constraint may not be enforced at the database level. Add a UNIQUE constraint or use INSERT ... ON CONFLICT to ensure atomicity.
Unicode characters cause encoding errors instead of validation errors -- Ensure the application correctly handles UTF-8 throughout the stack. The error should be a validation rejection, not an encoding crash.
Test passes locally but fails in CI -- Check environment differences: database collation settings, locale configurations, and time zone settings all affect validation behavior for strings, dates, and numbers.
Negative test generates false positive -- The test may be too strict about the error format. If the system returns a valid error but with slightly different wording, update the assertion to use a regex pattern rather than an exact string match.
Large payload test hangs instead of returning 413 -- The server may not have a request body size limit configured. Add body-parser limits (Express: express.json({ limit: '1mb' })) or equivalent middleware configuration.
