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
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...
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
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...
