Make your tests tell the story of your domain
summary
Legacy Norwegian court system runs 16 years of production with few bugs; the team automates the tedious quarter‑long manual regression cycles by writing value chain tests that exercise full workflows (death registration, notification flows) in Java/C#/Cucumber, uncovering that ~50% of cases follow alternate paths. Tests catch real quirks — a self‑owning house causes out‑of‑memory crashes — so they add explicit handling and regression checks. Tests double as readable domain documentation and enable collaborative (mob) testing across business and technical domains.
AI-written summary · about
chapters (29)
- 0:00Introduction
- 3:16We dont like testing
- 4:27Use the computer
- 5:49Dont repeat yourself
- 7:01Why test
- 7:35Types of tests
- 10:28What happens when you die
- 15:12Main path vs other paths
- 18:54Tests for sanity
- 24:35The technical domain
- 24:59Two languages
- 27:32Technical details
- 28:03Test classes
- 29:43Business tests
- 31:00Main purpose of production code
- 31:31Test functions
- 33:18Perfect memory
- 35:00Naming your tests
- 35:22Feedback loop
- 36:35Dont tell lies
- 36:51The deadline
- 37:57Real mocks
- 40:11Test marks
- 40:51Business domain
- 42:20Copypasting
- 43:17Type system
- 45:48Less double testing
- 46:55Catching bugs
- 47:51Summary
related talks
48mMake your tests tell the story of your domain
54mTesting in Legacy: From Rags to Riches
47mThe Valley of Success
01h 15mFrom Test Cases to Context-Driven: A Startup Story
36mIt's not your test framework, it's you
34mWriting end to end tests with a smile
47mTelling Better Stories with Tests
42mTest-Driven Repair