Editorial Note: I originally wrote this post for the Infragistics blog. You can check out the original here at their site. Go on over there for content from me and a bunch of other authors as well.
It’s pretty likely that you’ve heard of behavior-driven development, or BDD. Maybe it’s just in the context of buzzword fatigue and wondering “how many different approaches to software have acronyms that end with DD?” Whatever your level of cynicism, or lack thereof, BDD is worth a look.
A lot of my work over the last few years has involved coaching and mentoring on the subject of writing clean code, and I often tell initially skeptical developers that they should be writing methods that BAs and managers could more or less read (in places pertaining to business logic, anyway). This isn’t as far-fetched as it sounds. Think of a bit of code that looked like this.
public bool IsCustomerOrderValid(CustomerOrder orderToBeEvaluated)
foreach(var individualLineItem in orderToBeEvaluated.LineItems)
Would it really be such a stretch to imagine a non-technical person being able to look at this and understand what was happening? Take an order to be evaluated, look through each of its line items, and check to see if the product they contain is in stock. You don’t need to be a programmer to have an idea of what’s happening here.
BDD From 10,000 Feet
BDD in essence, is taking this idea and expanding upon it by making domain-oriented conversation a part of software acceptance. Don’t worry about “how” just yet. Suffice it to say that you and various non-technical stakeholders can sit down together and write tests, in plain English, that can be run to demonstrate that system requirements are being met. That’s pretty powerful.