Tests as executable evidence
Write checks that protect behavior, reveal boundaries, and remain useful when the implementation changes.
BY THE END, YOU CAN
- Choose meaningful examples and boundary cases
- Distinguish unit, integration, and system tests
- Explain what a passing test does and does not prove
Diagram description: Claim → Arrange; Arrange → Act; Act → Assert; Fake clock → Arrange (controls time); Fake clock → Act
Start with a claim
A test records a claim about behavior and checks it automatically. 'The delay never exceeds sixty seconds' is a useful claim; 'the helper is called once' may merely describe today's implementation.
Arrange a known input, perform an action, and compare the result with a meaningful expectation. Start with one ordinary example, a boundary, and an invalid case. Name tests after the behavior they protect so a failure explains what guarantee may have broken.
A green suite is evidence about covered cases, not proof of universal correctness.
def retry_delay(attempt):
return 60 if attempt >= 6 else 2 ** attempt
def test_retry_delay_is_capped():
assert retry_delay(10) == 60
def test_first_retry_delay():
assert retry_delay(0) == 1Test at the right boundary
A unit test checks a small behavior in isolation; an integration test checks collaborating components such as repository code and a real database; a system test exercises a complete user workflow.
Each finds different failures. A mocked database cannot prove that your SQL query works. A full browser test can show that the workflow succeeds but may give poor diagnostic detail when it fails.
Favor fast, focused feedback while retaining a few checks for important integrations. The appropriate balance depends on the risks in your application.
Control sources of uncertainty
Time, randomness, network availability, and shared state can make tests flaky.
Pass in a clock, seed a generator where appropriate, and isolate each test's data. For Relay, a fake clock makes a sixty-second retry policy test finish immediately. Add regression tests that fail for a reproduced bug and pass after its fix.
Consider properties as well as examples: a queue should never return more successfully removed jobs than were added. When a test fails intermittently, investigate the hidden dependency instead of repeatedly rerunning until it turns green.
COMMON FAILURE MODE
High coverage can still miss incorrect requirements and weak assertions. Measure whether important behaviors are protected.
TRY IT YOURSELF
Write tests for retry delays at attempts 0, 1, 5, and 10, plus the chosen invalid-input policy. Explain which case would catch a missing cap.
Make the call in the laboratory.
The two-question checkpoint, your notes, and your saved progress are in the laboratory. Free, with no account.
Open in the laboratory ↗CONNECT IT TO RELAY
Create Relay tests for FIFO order, empty queues, retry boundaries, and delayed-job readiness with a controlled clock.