3.6 Specification
Before coding we need to make sure our design has enough fidelity. Specification is about adding those details, the happy paths as well as the failure scenarios, so we're confident moving into coding.
Behavior Driven Development (BDD) is an important part of refining our specifications. Take a look at this short companion article to learn why BDD is so important and how it fills gaps that other quality and test practices don’t.
Introduction
This activity is about making sure we’ve taken the time to think about happy paths as well as failure scenarios. It’s about adding fidelity to our use cases so that our finished product is a quality product — one that our customers will enjoy using.
As part of that process, we’ll explore variations on the scenarios in our design. For example, we’ve defined a scenario to make a purchase — but what about when the credit authorization fails? Or the product isn’t available in the warehouse? Or our customer adds a duplicate product to the shopping cart? What should we do if the customer abandons their shopping cart?
Working with your team to think through these scenarios — poking each scenario, prodding to see if it stands up under pressure, adding new paths if it doesn’t — will help ensure our design is solid.
Writing good material is hard work — that’s why referrals are so important. Referrals let me know you like my work and keep me writing. Please share this article with a friend!
Building better specifications
This activity isn’t just about testing our assumptions — it’s about creating better designs. We want to be sure we’ve thought about how code will be used before we build it. This outside-in pressure tends to produce interfaces that are cleaner, more focused and easier to consume, as well as code that is more reliable.
