The discipline is now mainstream. A 2025 Postman industry survey<\/a> found that 67% of organizations used integration testing<\/strong>, the same share that used functional testing. The survey also reported that 82% had adopted some level of an API-first approach<\/strong>, while 25% operated as fully API-first organizations<\/strong>, up from 2024. REST remains the dominant API style, so integration testing is increasingly part of release readiness rather than an optional layer.<\/p>\n <\/a><\/p>\n The underwriting failure came from an integration boundary, not from an endpoint that crashed. Each service behaved correctly within its own process, while the provider and consumer disagreed about the payload exchanged between them.<\/p>\n <\/a><\/p>\n A unit test can construct a policy, call the connector, and assert that the application receives a successful response. If the provider client is mocked, that test may pass while the gateway rejects the live request because a field is missing, an enum is spelled differently, or a monetary value uses an unexpected format.<\/p>\n Sequencing creates another blind spot. A quote service might require authentication before a risk lookup, then require the returned quote identifier before accepting a payment request. Tests that call each handler independently will not reveal that production sends those requests in the wrong order. They also miss partial-success responses, content-type negotiation, or a retry that submits a non-idempotent operation twice.<\/p>\n Practical rule:<\/strong> A passing component test proves that one component behaves as designed. It does not prove that two independently changing systems still agree.<\/p>\n<\/blockquote>\n A real integration test sends an HTTP request through the client's actual serialization layer and checks the response as the consumer receives it. Test the headers, authentication, body shape, status handling, timeout behavior, retry policy, and persistence that follows the provider response. This can expose a field with the wrong meaning, a nullable value the deserializer cannot handle, or a response the application stores incorrectly.<\/p>\n Use a real dependency where its behavior is part of the risk. Mock a dependency when the scenario concerns your own control flow and the external behavior is already protected by a contract test. Keep those choices explicit. A mock is not a cheaper substitute for boundary coverage, and an end-to-end test is not a reason to run every case through every external system.<\/p>\n <\/a><\/p>\n REST testing research has moved beyond simple endpoint checks. A 2025 survey of REST API testing research<\/a> reported that fault detection is the most commonly applied metric<\/strong> in the field. The finding supports a practical focus on observable failures, rather than counting requests or endpoints alone.<\/p>\n A 2022 empirical study of black-box REST API testing tools examined 204 operations<\/strong>, reached 74% median operation coverage<\/strong>, and found previously unknown faults in four out of five APIs<\/strong>, with up to 21 unique faults<\/strong> in the best executions. Those results do not mean every team needs enormous generated suites. They show why a few happy-path requests cannot replace systematic checks for invalid states, dependency behavior, and unexpected responses.<\/p>\n The useful conclusion is narrower. Do not send every test through every external service. Select a real dependency, mock, stub, or contract test according to the failure risk, then place realistic integration tests around the assumptions most likely to break.<\/p>\n <\/a><\/p>\n Reliable integration scenarios start before the first request. If the environment, clock, credentials, and data aren't controlled, the suite will report environmental noise instead of product defects.<\/p>\n <\/a><\/p>\n Use Testcontainers<\/strong> to provision dependencies such as PostgreSQL, a message broker, or a local HTTP provider substitute. Create an ephemeral schema for the test run, seed only the reference data the scenario needs, and inject a deterministic clock so assertions don't depend on the current time.<\/p>\n A staging-like environment should include the components that influence the behavior under test. A database-backed quote flow needs a real database if persistence is part of the risk. A workflow that publishes an underwriting event needs a broker or a faithful fake if message delivery and serialization matter. The Speakeasy guide to API testing<\/a> recommends dedicated credentials, isolated environments, unique test data, teardown logic, and automated execution before production release.<\/p>\n <\/a><\/p>\n Use a clear Arrange, Act, Assert structure, then express the business intent in Given, When, Then language so developers and QA can review the same scenario.<\/p>\n Happy paths should include authorization, resource creation, retrieval, pagination, and update semantics. Negative cases deserve equal attention. Exercise expired tokens, insufficient permissions, malformed JSON, missing required fields, 429 rate limiting<\/strong>, and 503 responses with Retry-After<\/strong>. Boundary inputs should include empty arrays, Unicode names, null values, date formats, unexpected enum values, and maximum-length fields.<\/p>\n <\/a><\/p>\n Generate unique correlation IDs and test records through factories rather than copying static fixtures. Give each test its own tenant context, and clean up with compensating API calls where the system's behavior is part of what you're testing. A teardown that calls DELETE through the same integration boundary can reveal permission or cascading-deletion defects that direct database cleanup would hide.<\/p>\n A practical test-plan checklist looks like this:<\/p>\n <\/a><\/p>\n The right dependency isn't always the dependency. Consider an underwriting rules engine that calls a request-scoring API. A real provider can reveal authentic schema behavior, latency, authentication responses, rate limits, and failure modes. It can also make tests slow, stateful, expensive to coordinate, and vulnerable to provider maintenance windows.<\/p>\n A stub returns a deliberately selected response, such as a high-risk score or a temporary service failure. That makes it useful for fast consumer behavior tests. A mock goes further by verifying interaction details, such as whether the client sent the expected arguments, included an authorization header, or avoided duplicate calls. A fake, such as an in-memory rules store, implements meaningful behavior locally without depending on an external network service.<\/p>\n <\/a><\/p>\n Use a stub<\/strong> when the question is, \u201cDoes the consumer handle this response?\u201d Use a mock<\/strong> when the question is, \u201cDid the consumer make the correct interaction?\u201d Use a fake<\/strong> when you need realistic state transitions without external infrastructure. Use a real dependency<\/strong> when provider behavior, transport behavior, or cross-system persistence is the risk.<\/p>\n\nTable of Contents<\/h2>\n
\n
\n
\n
\n
\n
\n
\n
\n
Why Integration Tests Fail to Catch Critical Breakages<\/h2>\n
The passing test that proves too little<\/h3>\n
\n
Coverage is not the same as boundary confidence<\/h3>\n
Designing Repeatable REST Integration Test Scenarios<\/h2>\n
Prepare the environment deliberately<\/h3>\n
![\"A](\"https:\/\/figtrig.com\/blog\/wp-content\/uploads\/2026\/09\/rest-api-integration-testing-test-scenarios.jpg\")
<\/figure><\/p>\nDesign scenarios around behavior<\/h3>\n
\n
Keep every run isolated<\/h3>\n
\n
Choosing Real Dependencies Mocks and Stubs<\/h2>\n
Match the mode to the test intent<\/h3>\n
![\"A](\"https:\/\/figtrig.com\/blog\/wp-content\/uploads\/2026\/09\/rest-api-integration-testing-testing-pipeline.jpg\")
<\/figure><\/p>\n