DevOps · Operations

Automated Testing

Automated tests are what make frequent deployments safe. Without them, CI/CD just ships bugs faster.

Advanced 5 min Lesson 24 of 30
Before you start:CI/CD Fundamentals
0/30 in DevOps
On this page · 5 min · Advanced

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#

YAML.github/workflows/test.yml Illustrative
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
Expected output
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#

  1. Unit tests give fast feedback with coverage.
  2. Integration tests run against a real SQL Server container.
  3. needs: makes E2E wait for the cheaper tests.
  4. 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#

An inverted pyramid

Hundreds of slow UI tests make CI slow and flaky. Push tests down to unit level.

Chasing 100% coverage

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
Text Illustrative
A unit test — it is pure logic and runs in milliseconds.

Mini quiz#

Automated Testing quizMultiple choice Question 1 of 1

Which tests should be the most numerous?

Score so far: 0/0

Want more? Practise all DevOps MCQs · DevOps interview questions

My notes#

Saved in this browser.

Progress is saved in this browser. Sign in to sync.