Behavior Driven Development

After my last post on metrics, I came to the realization that what would be a much better approach to testing would be to focus on Behavior Driven Development. This methodology focuses on the use of scenarios to describe a small piece of functionality. Given its natural language approach to describing things, it provides an easily understood description of the requirements. For example:

Scenario 1: Refunded items should be returned to stock

• Given a customer buys a black jumper
• and I have three black jumpers left in stock
• when he returns the jumper for a refund
• then I should have four black jumpers in stock

From this, new advances in DSLs would provide a potential bridge to generate functional code to validate the requirements have been met. It seems to me this would provide a much higher value from a testing and code quality perspective as you are now writing tests that are 1) driven directly by the requirements; 2) oriented at a piece of functionality that directly affects the user.

Of course, some situations make this a difficult approach to use. For example, in my team's case, framework and API development would be somewhat more challenging to apply this approach. In order to overcome the lack of user-oriented scenarios, it may be necessary to approach it from an API-consumer perspective. A DSL here would perhaps help to bridge this gap, but still doesn't quite give the same clean application. Still, it seems like the benefits are there.

Something for us to consider as we move forward with our next release starting in January...