Short answer: An editor can write a test, but it cannot prove the response conforms to the API. A contract-verified workflow checks each response against the schema and flags the field that is silently wrong, so drift is caught at the moment it happens rather than in a flaky test or a staging incident.
The tests an editor writes well
Cursor is good at generating the happy path: arrange a request, assert a status, check a field. This covers the shape the model expects. The gap is that the test asserts the guess, not the contract, so a response that violates the API can pass if the test never looks at the offending field.
What contract verification adds
| Check | Editor-written test | Contract-verified |
|---|---|---|
| Status code | Yes | Yes |
| Specific asserted fields | Yes | Yes |
| Undeclared properties | Missed | Flagged |
| Missing required fields | Only if asserted | Flagged |
| Type drift anywhere | Missed | Flagged |
The failure that matters
The dangerous bug is the one the test does not look for: a new property in the response that was never declared, or a field that quietly changed type. Contract verification examines the whole response against the schema, so it does not depend on a human remembering to assert every field.
How the two fit
Use the editor to write the behavioral tests, and use the studio to verify conformance. They answer different questions: whether the code behaves, and whether the response is valid. Both are needed.
This is part of the Powerduck vs Cursor comparison. Next, read local mocking for agents.
Top comments (0)