Skip to main content

Cucumber Tags Naming Convention and Utilizing Tags

I was attending one of the Tech meeting in my current organization and the topic was "How to Get the Most Out of Cucumber Tags", There were few questions like can we execute in parallel on docker and selenium grid  based on tags like 1st tag execute on one instance and another set of tagged scenarios execute on 2nd instance.

While finding the solution they started over tagging the scenarios like for Layer 1 Menu one tag, Layer 2 Menu tag 2 and so on. Few of team member argued, With so many tags complexity of managing project and feature files will be increased. Several questions arise on Cucumber Naming Convention and Utilization.

Cucumber Tag Naming Convention

There is no ground rule in Cucumber about names.

  • Any string may be used as a tag.
  • Use @ symobol to tag feature or scenario.
  • First letter of each word capitalized. Try to keep your tag names simple and descriptive.
  • Use whole words-avoid acronyms and abbreviations
  • Avoid special symbols in tags name
  • You can not use multiple @ symbol and operators.

Tags Utilization

If multiple databases or environments are expected to be exercised with Cucumber tests, tagging is an excellent way to make reuse of test code. 

  • Any scenario or entire feature can have multiple tags associated with it. 
  • Scenarios inherit tags from the Feature statement.
  • Examples inherit tags from the Feature and Scenario statements.
  • Tags for data-environments: It’s easiest and simplest to design each feature file with at least one specific data-environment in mind. If multiple data-environments share common functionality, design the tests to run over as many as possible. The purpose is to indicate valid tests for each of the desired sets of data or environments. Each feature file should then be tagged with the intended data-environment. 
  • Tags for testing types: In addition to indicating tags for data-environments, tags should also be utilized for testing types. Scenario Outlines contain data tables to run over, and it’s an effective use of these tables to divide the tests run into Smoke and Regression tests. Create smaller subsets of the data for a Smoke test, and tag the larger tables as Regression. Additional testing types can also be rolling into this structure, with little effect on the tests.
  • Tags based on priority: Like P1, P2, P3.
  • Avoid Overtagging: Do not create so many tags that its hard to manage them.

Submitted by tgoswami on August 30, 2020

Tarun has 11+ years of experience in Quality Assurance in different domains like Banking, E-commerce, Health and Education.


At ProgramsBuzz, you can learn, share and grow with millions of techie around the world from different domain like Data Science, Software Development, QA and Digital Marketing. You can ask doubt and get the answer for your queries from our experts.