A status-200 check is not a contract test

A test that checks for HTTP 200 and stops there is not testing your API. It is testing that the server is awake.

I have been building a small tool that turns OpenAPI specs into runnable test suites. The hard part was never generating the code. It was deciding what a generated test is allowed to assert.

Here is the trap I keep running into in real public specs: every response is described as type: object, with no properties and no required fields. A generator can write a test against that, watch it return 200, and call it a pass. The suite is green and the contract is untested.

Two fixes, both in the spec:

1. Give response schemas real properties and required fields. If the body can be anything, nothing can fail.
2. Document the error responses. When 400, 401 and 404 have no shapes, the negative tests have nothing to check.

A generated suite is a mirror of the spec. A vague spec produces vague tests. So before writing a single test, I read the spec for the holes. That step is boring and it is most of the value.

Why a status code assertion is not enough

A status code assertion passes on an empty body too. Adding a schema check on the response turns a lot of those green tests red, which is the point. If required is missing, the generator has no reason to send the field, and the test proves less than it looks like it does.

Two more things I check before generating anything:

• 401 versus 403. A missing token should be 401. A valid token without permission should be 403. APIs that return 401 for both hide authorization bugs until production.
• Pagination edges: last page, empty page, an expired cursor, a limit larger than the server allows. Cheap to test, expensive to find in production.

None of this is novel. It is the work a fast generator will skip if you let it.

If you want a suite built

If you have an OpenAPI spec and want a runnable contract-test suite in 48 hours, that is what I do for $149. You send an OpenAPI 3.x file, YAML or JSON, public URL or shared file. You get runnable test files (pytest, Jest or Newman), a README with run instructions, and a short list of the spec gaps I found along the way. If I miss the 48 hours, you get a refund.

Details and checkout: https://itfabers.lemonsqueezy.com/checkout/buy/d1cbe20e-1358-466b-8af2-7cbfbff88636

If you want to check fit first, send the spec link in a comment.

I am an independent developer in Yerevan. I am not going to pretend I have a wall of logos. This is the offer, and the spec-gap audit is the part I think is worth paying for.