Integration and end-to-end testing in the pipeline
MS Learn module: Integration and end-to-end testing in the pipeline Learning objectives: run integration-testing and E2E tests during CI, provision realistic test data and dependencies, and use containers so tests run in a known environment.
Overview
Unit tests prove pieces in isolation; integration tests prove the pieces cooperate. This module is about running those higher-fidelity tests inside the build so regressions surface before release. CI gives a fast signal on every change, so integration coverage is a core quality gate.
Units / lessons covered
- Integration vs unit vs E2E — where each fits and which the pipeline should run and when; failing tests stop the build.
- Test data — fixtures and seeding a real persisted store (DB, queue, blob) so tests exercise realistic integration paths.
- Containers for tests — spin up dependencies in containers (e.g. testcontainers) to match prod; also a containerized test runner gives reproducible execution.
- Test isolation & parallelization — give each run its own schema/namespace so parallel agents do not collide.
Concepts introduced (link to term notes)
Key terms / commands
- Azure Pipelines:
npm test/pytest/junitsteps,- taskper test tier, artifact-based test reports,Test Resultstab - GitHub Actions: separate workflow
jobsfor unit/integration/E2E,actions/setup-node, containerized test runner
Hands-on / what to try
Add an integration test step to an existing pipeline that stands up a real Postgres container (or ACR image), seeds test data, runs the test suite against it, and publishes the failure report to block merge.
Exam focus
- Integration tests come after fast unit suites and before any deploy/release stage.
- Containers give deterministic test environments; test data must be separated so seeds don’t leak to prod.
- If integration blocks critical path, the pipeline can’t release until green.
Related
Path MOC · pipeline-security-controls · dependency-and-supply-chain