Search the practice set
275 questions, 991 terms and 600 topics in 30 areas.
60 results for “Integration Test Boundaries”
Test Double Boundary
The line inside a test between what is real and what is substituted, which determines exactly what the test can and cannot prove.
Testing Trophy
A distribution weighted towards integration tests rather than unit tests, appropriate where most of the risk lives at boundaries rather than in logic.
Boundary Volatility Test
Evaluating a proposed service boundary by asking whether the things on either side change for different reasons and at different rates.
Test Pyramid
A distribution of tests weighted towards many fast unit tests, fewer integration tests, and very few slow end-to-end tests.
Control Test Automation
Executing a control's test continuously against the whole population rather than sampling it annually, which changes both the detection latency and the strength of the evidence.
Differentiation Test
The question of whether a capability is a source of competitive advantage, used as the primary filter in build-versus-buy decisions.
End-to-End Test Cost Curve
How the cost of a broad end-to-end suite grows with its size while its marginal value falls, and where the two cross.
Enterprise Integration Patterns
A catalogue of named, composable messaging patterns — router, translator, aggregator, splitter, filter, dead letter channel — that gives integration work a shared vocabulary.
Event-Driven Integration
Systems integrating by publishing and consuming events rather than by calling each other's APIs.
File-Based Integration
Exchanging data as files on a schedule via SFTP or shared storage — dated, still ubiquitous, and workable when its failure modes are handled explicitly.
Integration Frequency
How often each engineer merges to the mainline — the measurement that distinguishes continuous integration from having a CI server.
Integration Landscape
The inventory of connections between systems, which is usually larger, less documented and more expensive than the application inventory itself.
Refactoring Under Test
Changing internal structure without changing behaviour, with tests as the mechanism that makes the claim verifiable.
Shared Database Integration
Two or more applications reading and writing the same database directly — the most damaging integration pattern and the hardest to unwind.
Soak Test
Running sustained realistic load for hours or days to expose defects that accumulate over time rather than appearing under peak load.
Stress Test
Driving load beyond expected capacity to observe how the system behaves at and past its breaking point.
Test Data Provisioning
Getting each test the data it needs, in a state it can rely on, without copying production personal data into a weaker environment.
Test Quarantine
Moving an intermittently failing test out of the blocking suite into a tracked, owned backlog, so a red build keeps meaning something.
Test Strategy Altitude
Deciding which risks are verified at which level, so that each layer tests something the layers below it structurally cannot.
API Gateway
A single entry point in front of a set of services that handles authentication, rate limiting, routing and protocol translation.
Six teams share one integration test environment. Bookings are made a week ahead and releases slip when someone overruns. How do you fix it?
Name the cost first The queue is not an inconvenience; it is lead time. Measure it: for the last twenty changes, how many days elapsed between "ready to test" a
A DR test fails: the secondary region cannot launch enough instances. What happened, and what standing checks prevent it?
What happened Service quotas in the secondary region are far lower than in the primary , because nothing has ever run there at scale. Quotas are per account and
A core mainframe system with no API supports nightly batch file exchange only. The business needs near-real-time order status. Design the integration.
Establish the real constraint "No API" usually means no API the mainframe team will build on your timeline . Find out what exists: message queue interfaces, dat
A team is splitting a monolith into services. How do you decide where the boundaries go?
The criterion is what changes independently Parnas's information hiding is the sharpest formulation: decompose around the decisions most likely to change , not
A team shows you a design with eight services. Without knowing the domain, what questions tell you whether the boundaries are right?
What the interviewer is testing Whether you can evaluate a structure from its properties rather than needing to be a domain expert in every system you review. T
Integration failures between 30 services are found in a shared staging environment, days after merge. Propose a change.
Why the current model fails A shared staging environment is a serialised, high latency feedback channel . Failures are found late, attribution is ambiguous (who
Netflix built its own CDN; Dropbox moved storage off S3. Both are usually wrong. What conditions made them right, and how do you test for those conditions?
What the interviewer is testing Whether you can extract the conditions from a famous decision rather than the decision itself. These two cases are the most comm
Run a threat model on a new payment integration: our service calls a third-party payment provider and receives webhooks. Where are the interesting threats?
Draw the boundaries first Three trust boundaries, and nearly every interesting threat lives on one of them: 1. User → our service (untrusted input, authenticate
The business has selected a SaaS product. You are asked to review the integration architecture after the contract is signed. What do you do?
Accept the position and be useful within it The selection cannot be reopened, and arguing about the process will spend credibility for nothing. What can still c
When should a service call another synchronously, and when should it publish an event instead? Give me the deciding test, not a preference.
The deciding test Does this user action succeed or fail based on this callee's response? If yes, the call is synchronous, because you need the answer to decide.
Your test quarantine has grown to 140 tests over a year. What has gone wrong and how do you recover?
What went wrong Quarantine without a cap and without a deadline becomes a graveyard. Each individual decision was reasonable — move the flaky test aside, raise
A downstream team needs to react to order changes. The order service can publish events, or they can consume CDC from its database. Which, and why?
The recommendation: published events, with CDC as the mechanism if needed The distinction that matters is what the consumer becomes coupled to . CDC consumed di
A service writes to its database and then publishes an event to Kafka. Sometimes consumers see an event for a record that does not exist, and sometimes a record exists with no event. Why, and how do you fix it?
What the interviewer is testing Recognition of the dual write problem — one of the most common defects in event driven systems and one that testing rarely catch
A team proposes exposing their service's database change stream via CDC so other teams can consume it, avoiding the work of building an event API. What is your assessment?
Name what is actually being proposed The proposal is to publish the service's internal schema as its integration contract. CDC does not emit domain events; it e
A team's CI suite fails roughly one run in three for reasons unrelated to the change. Everyone reruns until green. How do you recover the situation?
Recognise what has actually been lost The suite is no longer a gate. Once the team's reflex on red is "rerun", that reflex is applied to genuine failures too, a
Integration Test Boundaries
What sits inside a test's boundary, what is faked, and the confidence that follows.
Continuous Integration Discipline
Integrating to the mainline daily, and the test speed and review culture that requires.
API & Integration
General material on integrating systems through contracts.
Chaos as a Test
Fault injection with a hypothesis, a blast radius and an abort condition.
Domain Boundaries
Where the language of the business changes, and services should too.
End-to-End Test Economics
Why broad end-to-end suites get slow, flaky and abandoned, and what to keep.
Enterprise Integration
Estate-wide integration strategy, standards and shared infrastructure.
Event-Driven Integration
Publishing facts rather than commands, and versioning event schemas.
Flaky Test Management
Quarantine, detection, and the trust a suite loses once red stops meaning broken.
Integration Patterns
Routers, translators, splitters, aggregators and dead letter channels.
Legacy Integration
Reaching systems that cannot change, without importing their model.
Legacy Integration Patterns
Anti-corruption layers, adapters and CDC against systems that cannot change.
Non-Functional Test Strategy
Testing availability, latency, security and recovery rather than only behaviour.
Partner & B2B Integration
External contracts, onboarding, sandboxes and long deprecation windows.
Performance Test Design
Workload models, warm-up, think time, and the distribution the average hides.
Service Boundaries
Drawing lines along change patterns rather than technical layers.
Test Architecture Strategy
Choosing what to verify where, given the failure modes that actually occur.
Test Data Management
Realistic data without copying production personal data into a weaker environment.
Test Pyramid Shapes
Pyramid, trophy and honeycomb, and the system properties that justify each shape.
API Documentation
OpenAPI as a machine-checked contract rather than as prose.
API Error Handling
Error shapes, retryability signals and machine-readable causes.
API Versioning
URL, header and account-pinned versioning, and who carries the burden.
APIs as Products
Ownership, lifecycle, deprecation policy and developer experience.