Practices & Patterns
The disciplines that decide whether a test suite is trusted or skipped — AAA, given-when-then, TDD, BDD, page objects, dependency injection, test data and flakiness.
12 articles · updated 19 September 2026
You can tell how a team feels about its test suite from one question: when
the build goes red, does anybody look? A suite people trust gets fixed
within the hour. A suite people do not trust gets a retry, then a skip,
then a quiet deletion eighteen months later.
Almost nothing about which of those you end up with is decided by the framework. It is decided here.
#Four things that matter more than the tool
Structure. A test that a stranger can read in ten seconds gets fixed; a test they have to reverse-engineer gets deleted. That is all arrange-act-assert and given-when-then are for.
Design. Most "this is untestable" is a design complaint wearing a testing costume. Code that reaches out and grabs its own dependencies cannot be isolated, and no amount of mocking framework fixes it — see writing testable code and dependency injection.
Data. Where a test's data comes from decides whether the suite can run in parallel, whether it can run twice, and whether a failure at 3am is reproducible at 10am. Test data management is the most under-rated topic in automation.
Nerve. Flaky tests do not merely waste time. They teach people that red does not mean broken, and once that is learned it cannot be unlearned cheaply.
#Everything in this section
The practices split roughly into how you write a test (AAA, given-when-then, naming), when you write it (TDD, BDD), how you structure the code around it (page objects, the screenplay pattern, dependency injection, testable code), and how you keep it running once there is a lot of it (test data, parallel execution, flakiness).
They compound. A suite with good structure and bad data management is still flaky; a suite with clean data and untestable production code is still slow and shallow. The articles cross-link because in practice the problems do.
Everything in Practices & Patterns
Arrange-Act-Assert
foundationThe three-part shape every readable test has, why the act step should be one line, and the smells that show up when a test will not fit the pattern.
Given-When-Then
foundationThe Gherkin vocabulary for describing behaviour, how it maps onto arrange-act-assert, and when a shared specification language is worth its cost.
Naming and Structuring Tests
foundationTest names that say what broke without opening the file, the naming conventions worth adopting, and how to organise a suite so people can find things.
Test-Driven Development
practicalRed-green-refactor, what TDD actually changes about a codebase, where it fits badly, and the honest evidence for and against it.
Behaviour-Driven Development
practicalBDD as a conversation practice rather than a tool choice — what the three amigos session produces, when Cucumber earns its place, and how it fails.
The Page Object Model
practicalEncapsulating a screen behind a class so tests describe intent rather than selectors — what it fixes, the god-object failure mode, and modern alternatives.
The Screenplay Pattern
advancedActors, abilities, tasks and questions — a compositional alternative to page objects for suites with many user types and deep flows.
Dependency Injection for Testability
foundationWhy injected dependencies are the one technique that makes isolated testing possible, the three forms of injection, and how to do it without a container.
Writing Testable Code
foundationThe properties that make code easy to test — pure cores, injected edges, no hidden state — and the specific smells that make it hard.
Test Data Management
practicalWhere a test's data comes from decides whether the suite can run in parallel, twice in a row, or at all — builders, factories, fixtures and per-test isolation.
Running Tests in Parallel
practicalHow parallelism turns hidden coupling into failures, the shared resources that clash, and how to make a suite genuinely safe to run concurrently.
Flaky Tests
practicalWhy tests fail intermittently, the six root causes and how to fix each one, how to detect flakiness deliberately, and what to do with a test you cannot fix today.