How Gherkin can help you build the right thingBy Jason Roberts
We’re using the best tools. We have great programmers. We’re doing test driven development. We have continuous integration servers. We have 100% code coverage. We’re doing pair programming. We are following the best software engineering practices. We are building our software correctly. It’s awesome.
But… We’re building the wrong thing.
We have access to a great array of tools and an ever-increasing pool of knowledge about how to create well-engineered software. But even with all of the continued advances in software development, how do we ensure that our efforts are actually resulting in what the business, customer or end-user actually want.
If a feature is never used, it doesn’t matter how well it has been constructed. We have wasted time and money and potentially damaged our reputation in the eyes of the people we’re serving.
Agile software development practices (hopefully) bring us closer to the people we are building software for so as to reduce this potentially wasted effort. We may have Word documents outlining requirements in a SharePoint site, or we may be using cards on a window or wall. These techniques may work but do they actually represent what this system will do or is already doing?
Unlike automated tests, you can’t run a Word document or a piece of card on a wall. There is a gap between what the system is actually doing and what the specifications say it should do. It’s very easy for these two things to get out of sync. This is the problem that business readable domain-specific languages can help to address.
The Gherkin language allows us to create specifications that are easily comprehended by the business/user:
Feature: Adding to-do items
Scenario: New to-do tasks can be added
Given I’m on the task list screen
When I create a new to-do item
And give it a title of “Mow the lawn”
And choose save
Then the new item should be saved
And appear at the top of the to-do list
And be displayed as a newly added item
Once we have our Gherkin specifications we can ask the business to read them and check if:
- We are building the right thing
- We have missed any edge cases / scenarios
- There are more important things we should be building first
Ideally these scenarios should be created collaboratively with the business representative(s) and key people from the development team (for example a Tester, a Developer and a Business Analyst).
Once we know that we are building the right thing we can create automated tests for the scenarios.
SpecFlow is an open source tool for .Net developers that turns the steps in the scenario (for example: Given I’m on the task list screen) into methods in code where we can automate the system that’s being built.
We can now “execute” the specifications (scenarios) of the system, something we can’t do with Word documents or pieces of card.
These Gherkin scenarios (and their associated test automation code) are stored in the version control system, alongside the production system code that they describe. When test scenarios are run (for example as part of continuous integration build), if a test fails it’s an indication that the system has diverged from the specifications (or vice-versa).
Interested in learning more about Gherkin and SpecFlow? Check out Automated Acceptance Testing with SpecFlow and Gherkin in the Pluralsight library.
About the Author
Jason Roberts is a Microsoft MVP and Journeyman Software Developer with over 12 years experience. He is the author of the book Keeping Software Soft (KeepingSoftwareSoft.com) and writes at his blog DontCodeTired.com. He is an open source contributor and the creator of FeatureToggle, InAppPurchaseToggle and MoqaLate. He has also created both Windows Phone and Windows 8 Store apps. He holds a Bachelor of Science in computing and is an amateur music producer and landscape photographer.