Organising test code.
WHAT LAYERS TO SEPARATE
Tests, expressing intent Actions, expressing what a user does Interaction, dealing with the application Utilities and configuration
WHY SEPARATION MATTERS
Interface changes should require editing one layer, not every test.
WHAT A TEST SHOULD READ LIKE
The scenario, in business language.
WHAT IT SHOULD NOT CONTAIN
Selectors Waits Low-level interactions
WHAT TO PUT IN ACTIONS
Reusable sequences: signing in, creating a record, completing a purchase.
WHAT TO PUT IN UTILITIES
Data generation Setup and teardown Assertions used repeatedly
WHAT TO AVOID
Copying code between tests Deep inheritance hierarchies Logic in tests
WHY LOGIC IN TESTS IS A PROBLEM
Conditional tests verify different things on different runs.
WHAT TO ENFORCE
The same structure across the suite.
WHY
Inconsistent structure makes contribution difficult and maintenance slow.
WHAT TO DOCUMENT
How to add a test, and where each thing belongs.
WHAT TO REVIEW
Test code, as thoroughly as production code.
WHAT TO REFACTOR
The suite, as it grows.
