---
Background:
Ever since I first started using TypeScript, I felt that mocking HTTP responses was hard to scale with tools like MSW and Nock. Having used these libraries for a couple of years, primarily for testing, I often had to write, review, and duplicate a lot of custom abstractions on top of them, trying to ensure:
• Mock compliance: every mock should be realistic and accurate with the real service it represents; mocks with incorrect parameters, incompatible responses, or out of sync with the actual API directly reduce test confidence;
• Test completeness: if an application is expected make a number of requests with certain parameters, it should be clear from the tests what these expectations are and they should fail if not met;
How could a library help developers create better API mocks?
The insights I gained during my research led to the early drafts of @ zimic/interceptor and a published paper on IEEE (https://ieeexplore.ieee.org/document/11126628). From there, I started expanding Zimic's core principles to cover more aspects of the development process, not just API mocking:
• @ zimic/http: declare HTTP schemas, infer types from OpenAPI, and type native Web APIs.
• @ zimic/fetch: create type-safe Fetch API clients and have your requests and responses fully typed by default.
• @ zimic/interceptor: mock HTTP services in development and testing, and simulate responses with type safety.