Setting a Good Example - How to improve your SbE, BDD & ATDD Artefacts
summary
Argues that executable artifacts must serve three roles—specification now, test soon, documentation later—so write Gherkin/fitnesse files that are concise, coherent and include counterexamples. Shows failing examples (a 1,000‑word insurance feature, a vague payroll check, a noisy weekly statement) and a constructed working example (free delivery with VIP/quantity matrix). Recommends Cucumber/SpecFlow/FitNesse, start with the Then, keep a single when clause, automate regression runs and treat artifacts as living documentation to reduce rework and preserve long‑term value.
AI-written summary · about
chapters (32)
- 0:00Intro
- 0:19Setting a Good Example
- 1:08Improving
- 1:31The Alphabet Soup
- 2:05Artefacts
- 3:46Outline
- 4:45What is specification by example
- 6:06South America
- 8:23syndromes
- 10:09story
- 12:02text rings
- 12:15specific examples
- 13:25Whats the lesson
- 14:45Its more than a test
- 14:57Three important phases in its lifecycle
- 16:32Shortterm vs longterm
- 18:25Roles of specification
- 19:07What behaviour is relevant
- 19:55Test around the edges
- 20:39Coherence
- 25:02Hourglass shaped scenarios
- 25:55Focus
- 39:50Focus Balance Contrast
- 40:00Caveat
- 42:13Story time
- 45:09Whats the point
- 47:28Friends not food
- 49:11Facebook friends
- 49:21What are you
- 50:33We are friends
- 51:06Questions
- 52:50Maintainability
related talks
45mLet's talk about software behaviour (BDD)
40mMaking BDD Work for you
48mBDD - It’s More Than Acceptance Tests
09m"Effective ways of using BDD concept for Testing"
38mHow Are We Supposed to Know what We Should Create?
08m"BDD: NOT The Given-When-Then Thing"
36mHow Testers Can Help Paving the Future of Modern Requirements Engineering
34mDaniel Horn: BDD is Not a Testing Approach - How to Overuse BDD to Slow Down Your Delivery