When we migrated our API from .NET 4.6 to .NET Core, which was basically a complete rewrite, we needed one guarantee: every customer use case must return the same response. Unit tests couldn't provide that. And the effort of mocking dependencies across hundreds of endpoints would have killed our pace.

So we built a test suite where each test is a plain text file: an HTTP method, a URL, a request body, and the expected response. The entire test infrastructure is one file. Adding a test takes 30 seconds. The suite runs with every build inside our reproducible Docker pipeline. Builds fail if a test fails. No working infrastructure, no build. That's by design.

Six years and countless refactorings later, we run ~1,500 assertions per build covering every relevant customer scenario end-to-end. The test infrastructure itself was never refactored, only extended by new requirements like new authentication methods or binary response formats.
This talk explores why we deliberately inverted the testing pyramid, how it enabled us to move fast without breaking contracts, and why testing at the right boundary matters more than testing at every boundary.

Level: Intermediate
For: Backend developers, tech leads, and QA engineers who have felt the pain of maintaining large mock-heavy unit test suites that still don't prevent production bugs or who have been slowed down by test infrastructure that fights against refactoring.
Familiarity with REST APIs and basic testing concepts assumed. .NET knowledge helpful but not required.
Takeaway: A pragmatic alternative to the testing pyramid for contract-driven APIs, with 6 years of evidence that simplicity and velocity don't have to come at the cost of confidence.