The Invisible Gap Between Specs and Reality
Your team maintains a comprehensive OpenAPI specification. Every endpoint documented. Request schemas defined. Response structures mapped out.
Tests run. CI passes. Everything looks good. Then production breaks because an optional field wasn't validated, an error response was never tested, or an edge case slipped through - all while your spec said it should work.
The problem? Having a spec doesn't mean you're testing it. Documentation isn't validation.
What Schema Coverage Actually Shows You
Keploy's Schema tab bridges the gap between API contracts and test execution with line-level visibility into what you're actually validating.
Schema lines fully validated by tests
Referenced but not fully tested
No tests validating this definition
The Schema tab displays your exact coverage percentage (for example, "9.80% covered") and color-codes every line of your OpenAPI file so you can immediately identify untested endpoints, parameters, or response definitions.
Two Schema Views
Original.uploaded
Your raw OpenAPI specification — exactly as you defined and documented it.
Keploy's test-aware interpretation showing which schema lines are actively validated.
This separation makes the difference between what you documented and what your tests actually prove immediately obvious.
How It Works in Practice
Scenario · 80-endpoint E-commerce API
Without Schema Coverage
- Tests exist for login and checkout
- You assume the rest is covered
- Production breaks on an untested payment error response
- No visibility into gaps until after the incident
With Schema Coverage
- Open Schema tab → see 23% coverage
- Red highlights expose 15 untested endpoints
- Yellow highlights reveal partial payment validation
- Click "Cover missing lines"
- Keploy generates tests automatically
- Coverage jumps to 87% before deployment
Search + Action
Large APIs with hundreds of endpoints stay manageable with built-in schema search. Instantly locate specific endpoints, parameters, or response definitions.
Found uncovered sections? The "Cover missing lines" button triggers targeted test generation - no manual test writing required.
Why This Matters
Before
Manual Assumptions
- "We think this endpoint is tested"
- Manual assumptions
- Hidden gaps
- Surprises after release
After
Automated Validation
- Exact coverage visibility
- Contract-level accountability
- No blind spots
- Confidence before deploying
The Real Impact
Schema Coverage doesn't just show numbers - it enforces accountability for your API contract.
Every endpoint becomes observable. Every untested parameter becomes visible. Every gap between documentation and validation gets closed.
You're no longer guessing. You know exactly where your tests match your specs - and where they don't.
