1.
Introduction
2.
It passes all tests
2.1.
Test pyramid
2.2.
If testing is hard, inject what you need to verify
2.3.
Test doubles
2.4.
Test driven development
2.5.
Test coverage is not enough
2.6.
Tests must be reproducible
2.7.
No production code constants in tests
2.8.
Expand and contract
2.9.
Test for production
2.10.
Tests for distributed systems
2.11.
Performance tests
2.12.
Do not test external libraries 🏗️
2.13.
How to test UI 🏗️
2.14.
Linting 🏗️
2.15.
Test infrastructure 🏗️
3.
It expresses intent
3.1.
Naming
3.2.
Deep and narrow classes
3.3.
Immutability
3.4.
Generalise edge cases️
3.5.
Usually composition is better than inheritance
3.6.
Small classes and short methods 🏗️
3.7.
Homogeneity 🏗️
3.8.
Test naming 🏗️
3.9.
Comment the why 🏗️
3.10.
Visual indentation 🏗️
3.11.
Folder structure 🏗️
3.12.
Wishful thinking 🏗️
4.
It does not repeat itself
4.1.
One single authoritative knowledge representation
4.2.
Do not abstract by visual pattern matching
4.3.
Open-closed principle️
4.4.
Dependency inversion principle
4.5.
Information hiding️
4.6.
Wrap external libraries into custom classes️
4.7.
Polymorphism 🏗️
4.8.
Single responsibility principle 🏗️
5.
It does not contain superfluous parts
5.1.
Does not contain superfluous parts
5.2.
Clarify what is superfluous
5.3.
Do not abuse design patterns
Light (default)
Rust
Coal
Navy
Ayu
A Compendium of Software Design
Test naming
Mention [1] Characterization tests, chapter 13 of Working Effectively with Legacy Code - Michael Feathers
Mention "should" keyword
Mention multiple assertions
Make a case against generic terms like "correct" in favour of specificity