Automated Testing, TDD & Quality Engineering

Test Pyramids, Boundary Mocking, Playwright & CI Gates

5 modules, 24 lessons: What A Test Is For; Unit Testing In Practice; Test Doubles And Boundaries; Testing Time, Files And Services; Quality Gates And Code Review.

Beginner · 2 hours · 24 lessons · 80 labs

Who it is for

Beginner level.

For developers who write some Python and want tests they can trust: clear unit tests, sensible test doubles, fewer flaky tests and useful code review.

What you don't need yet:

What helps:

Before you start:

Take first:

Take next:

Learning paths:

Nobody needs to know everything before they start. Each course builds on the one before, so a learning path takes you there step by step.

Labs

80 labs, 49 of them graded: you write the code, it runs, and graded labs check the result. The outline lists each lesson's labs.

What is free

Start free: First 4 lessons free with an account. Pro: Every course, lab, handbook, practice exam and certificate.

Course outline

What A Test Is For

  1. The Cost And Value Of A Test (4 labs): You can say what a test buys you and what it costs to keep, and you can watch a test catch a regression the moment somebody introduces it.
  2. Arrange, Act, Assert (5 labs): You can write a test in three visible phases, and you can show that the phases make the failure report easier to read than a one line test.
  3. One Assertion Per Reason (5 labs): You can split a test so that each one fails for exactly one reason, and you can explain why the first failing assertion hides every assertion after it.
  4. The Test Pyramid And Where It Is Wrong (4 labs): You can explain what the test pyramid is really a picture of, mark the slow tests in your suite, and select or deselect them by marker.
  5. Coverage: Diagnostic, Not Target (4 labs): You can read a coverage report to find untested branches, and you can demonstrate a suite with full coverage that fails to notice a live bug.

Unit Testing In Practice

  1. Introducing pytest (4 labs): You can write and run a pytest suite with no configuration, read the session header, and select tests by name from the command line.
  2. Parametrised Tests (5 labs): You can check one claim against many examples with a parametrised test, give each case a readable identifier, and say when cases should be separate tests instead.
  3. Fixtures And Their Scope (5 labs): You can write a fixture with setup and teardown, choose its scope deliberately, and recognise the shared-state bug a wide scope invites.
  4. Naming Tests For Readability (5 labs): You can name tests so that a failure summary reads as a sentence, and use those names to select subsets of the suite from the command line.
  5. Making Failures Explain Themselves (6 labs): You can read a pytest failure report part by part, use approximate comparison for floats, and add a message that tells the reader what the numbers meant.

Test Doubles And Boundaries

  1. What Test Doubles Are For (5 labs): You can explain the four reasons to replace a collaborator in a test, introduce a seam by passing it in, and test an error path the real dependency will not produce on demand.
  2. Fakes, Stubs, Mocks And Spies (5 labs): You can name and write the four kinds of test double, and choose between them by what the test needs to observe.
  3. Why Over-Mocking Breeds False Positives (5 labs): You can spot a test that only verifies its mock script, replace brittle interaction checks with a behavioural seam, and make a broken system fail for the right reason.
  4. Testing Time And Randomness (4 labs): You can make time and randomness explicit dependencies, freeze them in pytest, and test boundary behaviour without sleeps or lucky seeds.
  5. Testing The Filesystem (4 labs): You can test filesystem behaviour with pytest temporary paths, assert the visible file contract, and avoid leaking state between tests.

Testing Time, Files And Services

  1. Flaky Tests And How To Kill Them (3 labs): You can identify a flaky test, reproduce the moving input, and replace timing luck with a deterministic boundary.
  2. Integration Testing With Containers (1 lab): You can decide when an integration test needs a real dependency, start it with a disposable container, and keep the test boundary explicit.
  3. Contract Testing Between Services (1 lab): You can define a consumer contract, run it against a provider, and see why contract tests connect API design with quality.
  4. Load Testing: Percentiles Over Means: You can read a load test percentile, distinguish typical latency from tail latency, and choose a service objective that users can feel.
  5. Testing With Real Databases (1 lab): You can choose database tests that deserve a real engine, isolate their data, and verify migrations and transactions without shared state.

Quality Gates And Code Review

  1. Code Review As A Quality Gate (1 lab): You can treat review as a quality gate, combine human judgement with automated checks, and ask whether a change is safe to merge.
  2. What To Look For In A Review (1 lab): You can review a change for behaviour, boundaries, failure paths and operational risk without getting lost in style debates.
  3. What To Automate Away (1 lab): You can automate mechanical review work, keep policy visible in tools, and reserve human attention for decisions automation cannot make.
  4. Writing Actionable Review Comments (1 lab): You can write review comments that name the risk, point to evidence, and give the author a clear next action.

Certification courses