What integration testing targets

Unit tests can pass while the product fails at boundaries. Integration testing verifies the interfaces, data contracts and behaviours between modules, services and external systems after individual components are tested and before full system acceptance.

Failure patterns

• mismatched field names, formats, time zones or units;
• authentication/permission propagation errors;
• duplicate, stale or partially written data;
• timeout, retry and idempotency mistakes;
• API version or dependency changes;
• calculations/reporting inconsistent across modules;
• error responses the UI cannot handle;
• production-like configuration missing from test.

Assigned case examples

• Healthcare: records, laboratory, radiology and CRM connections expose interoperability and data-consistency risk.
• E-commerce: payment and third-party services expose transaction, failure and security paths.
• Financial management: accounting, budgeting and payroll integration can produce calculation and reporting errors.
• Workday + SAP / Outlook + Salesforce: cross-platform workflows require data-integrity and business-purpose checks.

These examples come from a test-automation vendor article; use them to understand boundary risk, not as independent proof of the vendor’s product claims.

Scenario design

For each integration point:

1. identify producer, consumer, contract and owner;
2. cover normal, missing, invalid, duplicate and delayed data;
3. simulate dependency unavailable/slow/unauthorised;
4. verify both user-visible and stored-system outcomes;
5. check logs, alerts, retry and recovery;
6. confirm sensitive test data is protected;
7. add stable cases to CI/CD where cost and reliability allow.

Environment and data

• Match production-relevant versions/configuration.
• Use realistic but non-sensitive data.
• Control test setup and cleanup.
• Stub only when the risk is understood; at least one test should cover the real boundary.
• Record dependency versions and external limitations for handover.

Automation cautions

Automation increases repeatability but creates maintenance cost. Track flaky tests, false confidence, stale data, test-environment drift and gaps between mocked and live systems.

FIT5120 evidence

• Integration map with critical boundaries.
• Test matrix tied to acceptance criteria.
• Failure/recovery scenarios.
• CI/CD or repeatable execution evidence.
• Defect, fix and retest record.
• Known external limitations in Support/Maintenance documents.

Source

• Real-World Insights: Integration Testing Case Studies