Make your tests tell the story of your domain
summary
A 300,000-line Java monolith serving the Norwegian courts runs automated value-chain tests that exercise full workflows so product experts can read the domain story; tests also include technical facade checks and property tests that catch obscure edge cases. One unexpected bug — the property test "house owns itself" — once crashes production with infinite recursion and prompts a safety test that prevented recurrence. The team uses English for technical tests, Bokmål for business tests, and experiments with mob programming, Cucumber and FitNesse.
AI-written summary · about
chapters (26)
- 0:00Intro
- 0:40A project named Lovisa
- 1:47A long time ago in a Lovisa far, far away
- 2:58We don't like testing
- 4:27Use your computer
- 6:34Why do we write tests?
- 7:35What story do you want to tell?
- 8:19Tell the whole story
- 9:33What happens when you die?
- 11:18One test, several wins
- 13:44Value chain your unhappy paths
- 16:39Tell the quirks of the domain
- 20:36What is a domain?
- 22:10What is the technical domain?
- 23:17Different domains, different languages
- 25:35Tell the technical details
- 27:42Tell the business details
- 28:26Tests are as important as production code
- 30:18Tell the story bearing in mind that you'll forget things
- 31:36Naming tests
- 33:20Don't tell lies
- 34:31Use real mocks
- 38:52Beware the copy-paste fallacy
- 39:28Typing prevents domain lies
- 41:14Mob testing - useful for the whole team
- 42:58Long story short
related talks
49mMake your tests tell the story of your domain
42mTest-Driven Repair
02h 58mOverview of Testing in Our Applications
02h 46mThe Joy of Testing
45mTesting the untestable PART II – patterns, use cases and practices
46mProperty-based testing:You won't look at your tests the same way ever again
35mTest automation guide: How to move away from chain tests
48mThere is Such a Thing as Too Much Testing