# API Testing in Cursor vs a Contract-Verified Workflow

**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](https://www.powerduck.com/blog/powerduck-vs-cursor/). Next, read [local mocking for agents](https://www.powerduck.com/blog/local-api-mocking-for-cursor-agents/).