The five properties:

1. Fast — Tests should run in milliseconds, not seconds. Slow tests don't get run. A test suite that takes 10 minutes means developers stop running it before commits, which means bugs slip through. If a test needs a database, mock it. If it needs a network, stub it.
2. Independent — Tests should not depend on each other. No test should set up state that another test relies on. No ordering requirements. Every test should be runnable in isolation. Dependent tests create cascading failures that obscure the real problem.
3. Repeatable — Tests should produce the same result in any environment: local, CI, staging. No external dependencies on running services, specific data states, or wall-clock time. A test that passes on your machine but fails in CI is worse than no test at all.
4. Self-Validating — Tests should return pass or fail, not log files that require manual inspection. If a human has to read output to determine whether the test passed, it's not a test — it's a script. Assert explicitly.
5. Timely — Tests should be written just before the production code they verify (TDD). Tests written after the fact are written to confirm what the code already does, not to specify what it should do. They miss edge cases because the developer is already anchored on the implementation.

The Three Laws of TDD:

• (a) You may not write production code until you have written a failing unit test.
• (b) You may not write more of a unit test than is sufficient to fail (and not compiling counts as failing).
• (c) You may not write more production code than is sufficient to pass the currently failing test.

The Build-Operate-Check pattern for test structure: (1) Build the test data, (2) Operate on it (call the function under test), (3) Check the result. One pattern per test. One assert per test (ideally).