Using Cucumber its very easy to increase the cost of change for the software your features are testing. An example will illustrate this.

Say we have an ecommerce application that gives free postage if we buy more than $100 of products. We can write a simple feature to exercise this

    Feature: Free postage

    Scenario: Get free postage
      When I buy $110 worth of goods
      Then I should get free postage

    Scenario: Pay for postage
      When I buy $90 worth of goods
      Then I should not get free postage

If we have a little think about how this would be implemented we can imagine that the application will have the concept of a free_postage_threshold which is currently set to $100.

Now how much should it cost the business to change this value, say to $50. With our feature we’ve successfully increased the cost of change by making it necessary to do development to implement this change. We have to

1. Change the values in all the features that work with free postage
2. Change the value of our setting
3. Release our new version

If instead we had written our feature as

    Feature: Free postage

    Scenario: Get free postage
      When I buy enough goods to get free postage
      Then I should get free postage

    Scenario: Pay for postage
      When I buy insufficient goods to get free postage
      Then I should not get free postage

And implemented our step definitions to use the free_postage_threshold value, rather than a ‘magic’ number. Then the cost of change would be

1. Change the value of our setting

There might not even be the need for a step 2

It seems that many people in the Cucumber community think that reducing the cost of change in this manner is a bad thing. Ho hum …