Automated Testing
Automated tests are what make frequent deployments safe. Without them, CI/CD just ships bugs faster.
On this page · 5 min · Advanced
On this page
- Learning objectives
- Explanation
- Code example
- Step by step
- Real-world use
- Common mistakes
- Best practices
- Remember this
- Practice exercise
- Mini quiz
- Related topics
- My notes
- Reading time
- 5 min
- Difficulty
- Advanced
- Updated
- Oct 29, 2026
Related tutorials
Interview questions
Learning objectives#
- Apply the test pyramid
- Run unit and integration tests in CI
- Add a few end-to-end tests
- Keep test suites fast and reliable
Explanation#
Test pyramid: many fast unit tests, fewer integration tests (real database or API), and a handful of end-to-end tests through the UI.
Integration tests can use real dependencies in containers (Testcontainers) instead of mocks.
End-to-end tools such as Playwright drive a real browser for critical journeys like login and checkout.
Flaky tests destroy trust — fix or quarantine them quickly.
Code example: Tests in parallel jobs#
name: test
on: [pull_request]
jobs:
unit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-dotnet@v4
with: { dotnet-version: '9.0.x' }
- run: dotnet test tests/Shop.UnitTests --collect:"XPlat Code Coverage"
integration:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-dotnet@v4
with: { dotnet-version: '9.0.x' }
- run: dotnet test tests/Shop.IntegrationTests # uses Testcontainers for SQL Server
e2e:
needs: [unit, integration]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npx playwright install --with-deps chromium
- run: npx playwright test tests/e2e/checkout.spec.ts
Unit and integration tests run in parallel; the slower end-to-end checkout test runs only if both pass.
This example is illustrative. Copy or download it and run it in your own environment; the expected output is shown above.
Step-by-step explanation#
- Unit tests give fast feedback with coverage.
- Integration tests run against a real SQL Server container.
- needs: makes E2E wait for the cheaper tests.
- Only critical journeys get E2E tests.
Real-world use case#
A team deploys on Friday afternoons confidently because hundreds of tests run on every change.
Common mistakes#
Hundreds of slow UI tests make CI slow and flaky. Push tests down to unit level.
Test behaviour that matters; coverage is a guide, not the goal.
Best practices#
- Many unit, some integration, few E2E
- Real dependencies via containers
- Fix flaky tests immediately
- Run tests on every PR
Remember this#
Pyramid: unit > integration > E2E.
Fast tests first, slow tests later.
Flaky tests must be fixed.
Practice exercise#
Your task: Which kind of test should check that a discount calculation returns the right total?
Show solution
A unit test — it is pure logic and runs in milliseconds.
Mini quiz#
Which tests should be the most numerous?
Want more? Practise all DevOps MCQs · DevOps interview questions
My notes#
Saved in this browser.