Hi HN,
Having spent close to a decade working in the medtech industry, I’ve seen API test suites become brittle over time — not because the APIs broke, but because the tests asserted too much.
When you snapshot an entire response body, you're asserting every field, including ones irrelevant to the test. The moment your API adds a new field (a completely valid, non-breaking change), half your suite fails and you spend the afternoon clicking “update snapshot.” Nothing was actually wrong.
Skivvy's default is the opposite: assert only what you care about:
{
"url": "/api/users/1",
"response": {
"name": "Alice"
}
}
This passes even if the response contains 20 other fields. You declared that you care about name, so Skivvy checks name.
Tests are plain JSON files in git — no GUI, no export step, no proprietary format.
State can pass between tests declaratively ($store / <variable>), so auth flows and chained requests work without imperative hooks. Custom matchers are simple Python functions if you need to go beyond the built-ins.
We've used Skivvy for all backend API tests at my current company for a couple of years.
Curious whether others have landed on similar patterns — especially when dealing with hundreds or thousands of tests.
jonasholmer•1h ago
Happy to answer questions about how people structure larger test suites or how the matcher system works.
jonasholmer•1h ago
This passes even if the response contains 20 other fields. You declared that you care about name, so Skivvy checks name. Tests are plain JSON files in git — no GUI, no export step, no proprietary format. State can pass between tests declaratively ($store / <variable>), so auth flows and chained requests work without imperative hooks. Custom matchers are simple Python functions if you need to go beyond the built-ins. We've used Skivvy for all backend API tests at my current company for a couple of years. Curious whether others have landed on similar patterns — especially when dealing with hundreds or thousands of tests.