Integration testing for the places where systems have to agree
Individual components can all pass and the product still fail, because the failure lives between them: a renamed field, a retried message, a vendor sandbox that behaves differently. We test the boundaries on purpose, including the asynchronous and failure cases.
Overview
What it is. Integration testing verifies that components, services, databases and third-party systems work together: that data crosses each boundary correctly, that timing and ordering are handled, and that failures at one end are handled sensibly at the other.
Who it is for. Teams building with microservices, platforms combining internal and third-party services, products depending on payment, identity, messaging or data providers, and organisations merging systems.
Why it matters
The problem it addresses. Component tests do not see boundary problems. End-to-end tests see them too late and too slowly. Boundary-level tests are the efficient place to find them, but they need deliberate design.
When it matters most. When a new integration is added, when a vendor or internal contract changes, when moving to event-driven or asynchronous designs, and when incidents trace back to 'it worked in isolation'.
What happens without it. Defects surface in production as duplicate transactions, missing updates and mismatched data, and take a long time to trace because they belong to no single component.
What we test
Integration map
every boundary, its type and its owner
Synchronous calls
request and response agreement, errors, timeouts and retries
Asynchronous flows
events, webhooks and queues, ordering, duplicates and delays
Data consistency across systems of record and downstream stores
Third-party integrations
sandbox behaviour versus production, rate limits and outages
Failure handling
what happens when a dependency is slow, wrong or unavailable
How UpDoer approaches Integration Testing
Understand
Requirements, tickets, code diffs and product context.
We collect architecture diagrams, API descriptions and incident history, and ask which integrations have hurt before.
Risk Mapping
Where a failure would cost the most.
We rank boundaries by business consequence and by change frequency, and flag the ones that move money, identity or personal data.
Test Strategy
Coverage chosen, test cases drafted.
For each boundary we decide whether to test against a real system, a sandbox or a simulation, how data is created and cleaned up, and how timing is handled.
Execute
Manual and automated testing runs.
Tests run in isolated environments, triggering events and waiting for outcomes, then checking data on both sides, plus deliberate failure injection.
AI-Assisted Quality Engineering
Failures classified, release risk scored.
AI helps follow a failed transaction across logs, drafts scenarios from diagrams and groups failures by boundary and cause.
Human Verification
A QA engineer checks every flagged result.
A QA engineer interprets timing and consistency results, judges whether a vendor or a team owns a fault, and confirms what is a defect.
Report & Improve
The verified quality signal, then better coverage.
We report by boundary with its tested and untested paths. New incidents become new checks, and the integration map stays current.
Integration: where systems have to agree
01
Where it breaks
Renamed field, silent breakDuplicate or late eventsVendor sandbox differs02
Test workflow
Service AAPIService BVerify03
AI assists
Trace failures across logsDraft boundary casesGroup by boundary04
Humans decide
Real or simulated?Is the delay acceptable?05
Release signal
Coverage by boundaryUntested paths listedRelease call by a person
Illustrative workflow. Not a client result or a measured outcome.
Integration boundary matrix
A dash means no AI step is described for that area.
| Boundary type | What we validate | AI assistance | Human validation |
|---|---|---|---|
| Synchronous API call | Request and response agreement, timeouts, retries, error mapping | Drafts cases from the interface description | Judges retry and timeout behaviour |
| Event or webhook | Delivery, ordering, duplicates, delay handling | Traces an event through logs | Decides what delay or duplication is acceptable |
| Batch or file transfer | Format, volume, partial failure, reruns | — | Confirms reconciliation rules |
| Shared data store | Consistency, locking, migration effects | — | Judges data ownership issues |
| Third-party service | Sandbox versus production differences, rate limits, outages | — | Handles vendor liaison and risk acceptance |
| Identity and payments | Sign-in, token exchange, payment lifecycle | Suggests state-transition cases | Assesses security and business impact |
Boundary type: Synchronous API call
- WHAT WE VALIDATE
- Request and response agreement, timeouts, retries, error mapping
- AI ASSISTANCE
- Drafts cases from the interface description
- HUMAN VALIDATION
- Judges retry and timeout behaviour
Boundary type: Event or webhook
- WHAT WE VALIDATE
- Delivery, ordering, duplicates, delay handling
- AI ASSISTANCE
- Traces an event through logs
- HUMAN VALIDATION
- Decides what delay or duplication is acceptable
Boundary type: Batch or file transfer
- WHAT WE VALIDATE
- Format, volume, partial failure, reruns
- AI ASSISTANCE
- —
- HUMAN VALIDATION
- Confirms reconciliation rules
Boundary type: Shared data store
- WHAT WE VALIDATE
- Consistency, locking, migration effects
- AI ASSISTANCE
- —
- HUMAN VALIDATION
- Judges data ownership issues
Boundary type: Third-party service
- WHAT WE VALIDATE
- Sandbox versus production differences, rate limits, outages
- AI ASSISTANCE
- —
- HUMAN VALIDATION
- Handles vendor liaison and risk acceptance
Boundary type: Identity and payments
- WHAT WE VALIDATE
- Sign-in, token exchange, payment lifecycle
- AI ASSISTANCE
- Suggests state-transition cases
- HUMAN VALIDATION
- Assesses security and business impact
Where AI helps
- Tracing a failed transaction through logs from several services and pointing at the boundary where it went wrong.
- Drafting integration scenarios from architecture diagrams and interface descriptions for review.
- Grouping failures by boundary, payload type or time window so repeated causes are investigated once.
- Suggesting regression candidates when an interface changes and has known consumers.
- Summarising which boundaries were exercised and which were not.
How we use AI: AI can accelerate test design, analysis and repetitive QA work, but important outputs remain subject to human review and validation. It informs the release decision; it does not make it.
Where humans matter
- Deciding where a real dependency is worth the cost and where a simulation is enough.
- Interpreting eventual consistency: whether a delay is acceptable or a defect.
- Judging whether a fault belongs to your team, another team or a vendor, and what to ask them.
- Designing failure scenarios that reflect how dependencies actually fail.
- Owning the decision to release with a known gap at a boundary.
Tools we build with
- Automation
- SeleniumPlaywrightAppiumKatalonTestComplete
- API & Performance
- PostmanSoapUISwaggerApache JMeter
- CI/CD & Reporting
- JenkinsTeamCityAllureMaven
Related services
Relevant industries
Frequently asked questions
How do you test integrations with vendors that have limited sandboxes?
We find out in scoping what the sandbox does and does not reproduce, test what it can, simulate the rest and clearly list what remains untested against the real service.
How is integration testing different from end-to-end testing?
Integration tests check specific boundaries quickly and precisely. End-to-end tests run a whole journey and are slower and more fragile, so we use fewer of them.
Can you test asynchronous systems?
Yes. We design tests around events and their outcomes, waiting for the right signal rather than guessing with fixed delays, and check ordering and duplicates.