Learn about Cucumber Features in part two of our How-To-Guide on applying the framework to lead your agile testing team down the path to automation.
Blog two of a series.
Now that your Cucumber project has been created and Gherkin scripts are in hand, your agile testing team is ready to automate.
But, before we jump into coding, a few concepts need to be explained.
The first concept is Features. Other concepts – Scenarios, Gherkin scripting, and WebDriver – will be discussed in future blog entries.
Depending on which agile tool you use or which agile book you read, user stories are sometimes referred to as a Feature. For us, they are one in the same. Both describe, from a user point of view, a requirement the business is requesting.
Authors of the The Cucumber Book define Features as groups of tests, stating “…we want them to describe the features that a user will be able to enjoy when using our program.”
That is a pretty good definition since we are going to be placing our Acceptance Script(s) in the Feature file along with any additional test cases we come up with. Each Feature is placed in a .feature file that resides in the project/features directory.
Creating a File in Cucumber Features Directory
To create a .feature file in Cucumber:
- Right-click on the <project>/features directory.
- Select New -> File.
- At the prompt, enter <feature name>.feature and hit Enter.
This will create a .feature file in the Features directory:
There are a couple of things every agile testing team should notice:
- The new feature file’s icon is green. This is a good thing as it indicates the framework recognizes it as a Cucumber .feature file.
- On the right side of the IDE is your new .feature file, which is ready for your acceptance tests.
Adding a Title in Feature File
To finish this lesson, we need to add a title to our .feature file.
Put your cursor on the first line of the .feature file and type: “Feature: <User Story title>”. It will look like this:
The space below the Feature line and the first Scenario (more on this in the next blog on Thursday) is a white space where you can write anything you want.
I always recommend adding the User Story and Acceptance Criteria. This is invaluable for future BDD agile testing teams, developers and analysts who will use this file as system documentation.
You can also add functional notes, notes from conversations with the team, and anything else you feel enhances the feature knowledge of a future agile testing team member.
Features are a critical component of the BDD and ATDD process, as well as the Cucumber framework. They are a storage location for all tests of specific functionality and help future users understand the System Under Test (SUT).
Next week we will be exploring test cases. Or, as they are known in Cucumber: Scenarios.
- Read the rest of the series.
- Does your organization need comprehensive training on BDD, ATDD, Cucumber (in multiple technology stacks) or WATiR? Contact us for more information.
- Read more about Cucumber in this blog: A BDD Tool for Your Agile Testing Tool Belt.
- Learn more about the Software Quality Assurance & Testing Practice.
About the Author
Matthew Eakin is the National Manual Testing Architect with Centric’s Software Quality Assurance & Testing Practice. With over 20 years of technical, leadership and planning experience, his experience in all aspects of the SDLC, combined with development skills, has helped Matthew to be an effective Agile testing practitioner and coach. He talks extensively on Gherkin Scripting and is in high-demand as a BDD (Behavior Driven Development) and ATDD (Acceptance Test Driven Development) coach, and his workshops (Agile Testing, Gherkin Scripting, and A Manual Testers Guide to the Ruby/Cucumber Framework) have been so successful that Matthew has led the series nationally and teaches customized variations of the program at client sites. Follow Matt on Twitter.