Following on from our previous post on 'Cucumber Best Practices,' we have compiled a list of 15 export suggestions to bear in mind when working with Gerkin language and Cucumber.
In retrospect, for this case we find that certain methods of doing things are simply superior to others, so here are a few to keep in mind, we'll make a quick comment on each one.
1. Organize your features and scenarios with the same care that you do your code.
The speed with which things move is a handy approach to arrange them. For this, use 2-3 levels of granularity:
- Fast: scenarios that run very quickly, for example, in less than a tenth of a second.
- Slow: scenarios that are slower but not painfully so, maybe less than a second apiece.
- Glacial: scenarios that take an extremely lengthy period to complete.
- Put them in different features.
- Separate them into subdirectories.
- Tag them
2. Feature Files Should Only Include Features, Not Entire App Portions
Please, one feature per well-named file, and keep the features focused.
3. Avoid Domain Language Contradictions
When your consumers are participating, you will get the maximum benefits from adopting Cucumber. To that purpose, while writing stories, make sure to employ their domain language. The best line of action is to include them in the writing of the stories.
4. Don't Get Caught Up in Backgrounds (Stick to Givens)
The higher the background, the bigger the comprehension burden for each scenario. Scenarios that include all of the facts are self-contained and hence more comprehensible at a glance.
5. Run Features Using Rake Tasks
This creates a consistent environment for running features by using the same set of options and settings for each run. This contributes significantly to the preservation of predictable findings.
Another advantage is that it is simple to integrate with continuous integration technologies. All options/parameters are wrapped at a single point of entry into the standard run.
6. Make Use of Tags
Tags are an excellent method to arrange your features and scenarios in non-functional ways. @small, @medium, and @large may be used, as could @hare, @tortoise, and @sloth. Using tags allows you to keep a feature's scenarios structurally cohesive while running them independently. It also makes it simple to move features/situations across groups and split a specific feature's scenarios among groups.
The benefit of dividing them in this manner is that you may run scenarios at various times and/or frequencies, i.e. run quicker scenarios more frequently, or run extremely large/slow scenarios overnight on a schedule.
Tagging may be used for more than only categorizing scenarios based on their speed:
When should they be run: on @checkin, @daily, @hourly
They have the following external dependencies: @local, @database, @network @functional, @system, @smoke
7. Create Non-Happy-Path Case Scenarios As Well
Happy path tests are simple; edge cases and failure scenarios require more thinking and effort. This is where having some competent (but pathological) testers on the team may pay off.
Use rcov in conjunction with your entire Cucumber runs to identify coverage gaps. For further information, see Aslak Hellesoy's comments on the subject.
8. Make scenarios self-contained and deterministic.
There should be no interdependence between possibilities. State that endures between situations is the primary source of such coupling. This can be unintentional or, worse, intentional. For example, one scenario may walk through the process of adding a record to a database, and future scenarios can rely on the existence of that record.
This may work, but it will cause problems if the sequence of the situations changes or if they are played in simultaneously. Scenarios must be totally self-contained.
Every time a scenario is run, it should provide the same outcomes. A scenario's objective is to describe how your system operates. If you don't have faith that this is always the case, it's not doing its job. Find out why you have non-deterministic cases and correct them.
9. Develop Your Language Using Compound Steps
Compound steps (calling steps from steps) can assist make your features more precise while keeping your steps general—just don't overdo it. As an example:
Given /^the user (.*) exists$/ do |name|
# ...
end
Given /^I log in as (.*)$/ do |name|
# ...
end
Given /^(.*) is logged in$/ do |name|
Given 'the user #{name} exists'
Given 'I log in as #{name}'
end
10. When parsing time in your step definitions, use a library (such as Chronic).
This allows you to use time naturally in scenarios. This is very important for determining relative times.
Background:
Assume a person registers up for a 30-day trial account.
Scenario: Access before the expiration date
When they login in 29 days
Then they will be let in
Scenario: access after expiry
When they login in 31 days
Then they will be requested to renew their subscription
11. Follow the DRY principle by refactoring and reusing step definitions.
Look for opportunities to create reusable step definitions that are not feature specific. As a project progresses, you should collect a library of step definitions. Ideally, you'll end up with step definitions that can be used to different projects.
12. Go back over, Refactor, and improve your Scenarios and Steps.
Look for ways to generalize and reuse your steps. You want to build up a reusable library of steps such that adding new features becomes easier and easier over time.
13. Refactor Language and Steps to Reflect Better Domain Understanding
This is a continuation of the previous point; change the language used in your scenarios as your grasp of the domain and your customer's language/terminology increases.
14. Use Parallel Step Definitions to Support Different Features Implementations
Running features against Webrat and Selenium, for example. Put these step definitions somewhere they won't be auto-loaded, and make them available through the command line or rake job.
15. Do Not Use Conjunctive Steps
Each step should only do one thing. Step patterns with the word "and" should be avoided in general. As an example:
Given A and B, the following procedures should be taken:
Given A & B
In Conclusion
There are countless methods to make the most of Cucumber and Gherkin Language to enhance your overall Cucumber and Gherkin syntax practices; the list above is by no means exhaustive and you .
When you need everyone on the team to be informed without delving into technical details, Gherkin and Cucumber might be an excellent alternative. The option is yours, but before you do, thoroughly analyze the benefits and drawbacks of each syntax and solution. The most crucial thing is that you and your team have access to the appropriate tools for your development tasks.
In this TestQuality blog we have discussed in previous posts what Gherkin testing is, how to construct Gherkin tests, and the advantages and disadvantages of utilizing this syntax. We hope these posts have provided you with some ideas on the best language and testing alternatives for your next project.
TestQuality and Gherkin
TestQuality's import capabilities also allow you to import requirements, tests, and issues by uploading Gherkin Feature Files easily with an import data option menu even when using a Gherkin based Test results JSON file.Gherkin feature files can be uploaded via TestQuality REST interface via curl, a popular command line tool.
Once your file has been added, you can optionally choose a Cycle and Milestone that you would like to link to your Test Run result.
Gherkin Feature Files with your tests can be easily imported with TestQuality
TestQuality is designed around a live integration core that allows TQ to communicate directly with GitHub and integrate with Jira in real-time linking issues and requirements with the key tools in your DevOps workflows.
Join now and Try TestQuality for Free!