I like to try multiple different approaches to solving a problem to see how they compare. I might learn something from one approach that I could apply to another. As an example, I created an alternative approach to calculations with fractions. The fraction idea comes from J.B. Rainsberger’s class on Test Driven Development. It is a great demonstration of TDD.
In this example, I’m going to use Gherkin as the specification language for the customer facing behavior For applications where the external behavior and its component parts are specified by the customer and/or stakeholders, having examples in Gherkin can dramatically decrease the communication impedance between the customer and the developer. PDF is here. HTML is here.
There is a flow from external requirements to internal tests. Requirement Driven
Development (RDD) (aka Behavior Driven Development / Acceptance Test Driven
Development / Specification by Example) focuses on the external behavior.
Test Driven Development focuses on the internal behavior that creates the
external behavior. There is an overlap between the two. TDD can go all the
way up to external behavior. RDD can differentiate into more detailed
behavior. Go here for html. Go here for PDF.
This kata revolves around a common domain term – money. Money appears in many applications, so the code from this kata might be adapted to those applications. Although it uses a dollar, it’s easily changeable to the currency of your choice by just replacing the currency symbol. Since requirements /tests written in Gherkin are implementation independent, you can implement this in any language. Some languages may be easier than other since they have more extensive libraries. Programmers can try multiple implementations and then have discussions as to the relative merits of each one.
The full kata in a PDF. The kata in html.
The kata is released under the Creative Commons copyright.