A successful request proves only that the happy path works. It does not tell you how the API behaves when the input is incomplete, malformed, unexpected, or too large.
Most real defects appear when application assumptions are violated. That is why every endpoint should be tested not only with valid data, but also with invalid input.
For a user creation endpoint, a valid request might look like this:
{
"name": "John Smith",
"email": "john@example.com",
"phone": "+971501234567"
}
That request confirms that valid data is accepted. However, it does not answer more important questions:
- What happens when a required field is missing?
- What happens when email contains an invalid value?
- What happens when a string is replaced with a number?
- Are null values accepted?
- Are empty strings rejected?
- Are unexpected properties ignored or stored?
- What happens when the payload is extremely large?
- Does malformed JSON result in a controlled error?
A common API defect is returning HTTP 500 Internal Server Error when the client sends invalid input. The server should reject malformed data with a clear client error, not fail internally.
Oversized values are another important example. An API may accept a user name containing several megabytes of text and return a successful response. The problem might appear later in a report, mobile application, search index, integration, or analytics pipeline.
This makes invalid input testing more than a validation check. It is also a reliability, security, and operational stability check.
At minimum, every endpoint should be tested with:
- Missing required fields
- Invalid formats
- Incorrect data types
- null values
- Empty values
- Boundary values
- Oversized strings
- Oversized payloads
- Malformed JSON
- Unexpected properties
The expected result should normally be a controlled 4xx response with a meaningful validation message.
Invalid input should never cause application crashes, database corruption, service instability, unbounded memory consumption, or unexpected HTTP 500 responses.
With Rentgen, this type of testing does not require a large test suite to be written manually. Start with a working cURL request, describe what the fields represent, and let the tool explore variations around the expected input.
The goal is not only to prove that valid requests work. The goal is to discover what happens when the assumptions behind those requests are wrong.
That is where many serious API defects begin.
This is the second rule from The Power of Ten – Rules for Testing HTTP APIs:
https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html
Top comments (0)