Integration testing

What it is

Integration testing verifies that components work together after unit tests have proven each in isolation — exercising the real interfaces between application code and its dependencies (databases, queues, APIs, containers, and end-to-end user flows).

Why it exists

Unit tests catch defects inside a unit; integration tests catch defects between units: wrong contracts, mismatched schemas, deployment/ordering issues, and cross-service behavior that only appear once pieces are combined. Catching them in CI is far cheaper than in production.

Key ideas

• Works on the test pyramid: many fast unit tests, fewer slower integration tests, fewest E2E.
• CI should run a pragmatic slice of integration tests on every change, with the full suite on merge/release.
• Test data is seeded, disposable, and isolated per run so parallel agents don’t collide.
• Containers provide known dependencies for tests (databases, brokers, test brokers, queues) giving a repeatable environment.

Exam notes

• Integration tests run after unit suites, before release/deploy stages.
• Containers & seeded test data = the “realistic but isolated” test lab story.
• A failing integration test (or E2E) is a hard gate that trips quality gates and blocks release.
• Distinguish unit (isolated) vs integration (components combined) vs E2E (whole system) — a frequent exam taxonomy.

Related

pipeline-integration-tests · azure-pipelines · build-artifact · pipeline-security

📘 Source: Microsoft Learn — Test your code