Structuring Feature files.

Structuring Feature files.


With multiple developers writing tests on the same project, inconsistent Feature File structure can lead to overlaps in test coverage and reduce test readability.


Adopting a modular approach

Many common computer interactions are reused when performing tasks even across functional areas. If an interaction is reused more than once, it should be modularized. This modularization relies on importing Feature Files and reusing Scenarios. There are a number of reasons to implement a modular approach to Feature development with Cycle:

  • Reusability: Breaking functions up into their own Scenarios means that a given Scenario can be imported and reused across Features. This removes the need to rewrite the same Scenario over and over.
  • Customizability: Customizing an environment for a given set of tests, for example, becomes more efficient when it can be configured in one Scenario instead of across multiple Features.
  • Maintainability: When software changes, our tests need to change. It is much quicker to update one Scenario that is shared across Features than to update each individual Feature.
  • “Debugability”: When Feature execution does not produce the desired results, it is easier to drill down into a specific Scenario and identify the subset of Step(s) to debug, instead of wading through longer lists of Steps under the main Feature.
  • Readability: By reusing Scenarios, top-level Features can be shorter, and more focused on highlighting the business process as opposed to the detailed Steps to execute that business process.

It is therefore recommended that different functions be written into discrete Scenarios. Like Scenarios can then be grouped into the same Feature, for efficient importing and reuse by other functional Features.

One example of a useful way to implement modularization is to create a Feature File, named “Environment.feature”, containing Scenarios to configure the environment(s) for a given set of tests. This Feature can then imported into main Feature Files via the Background of Feature Files, or directly into functional Scenarios when it makes sense. Environment.feature could contain Scenarios that configure setup data like connection Information (connection strings, user, password), device codes, or any other data that might be specific to a PC or user.

Feature structure

A Feature File is made up of the following sections, in the following order: 


1. Feature Header (optional, but recommended) - Using comments, a Feature Header section should be added to the beginning of all Feature Files to specify the Cycle version and the application version being tested, assumptions, and usage instructions. 


2. Background (optional, one per Feature) - The Background (one per Feature) is a specific type of Scenario that runs prior to every non-@wip Scenario in a Feature File. In many cases, it is useful to import Environment.feature via the Background. As described above, Environment.feature would contain Scenarios to set up the test environment for the Scenarios. 


3. After Scenario (optional, one per Feature) - The After Scenario, which runs after each non-@wip Scenario in a Feature, can be used for cleaning and purging data used in Scenarios. 


4. Functional Scenarios - Functional Scenarios are the main, function-specific execution Scenarios and @wip Scenarios included in the Feature File.

Recommendations for Scenarios

  • A Scenario should contain a single complete and independent test.
  • A Scenario should not be dependent on a specific Feature or Scenario running first to setup the data or the application.
  • Exception: It is acceptable to build Scenarios that expect a common state (for example: the terminal or GUI application to be logged in and at the main menu). These Scenarios should always start by testing to confirm the appropriate starting condition.
  • A Scenario should only be dependent on other Scenarios that get called/run from the Scenario.
  • Note: While developing a long Scenario it is common to create a Feature containing a series of small Scenarios that run in sequence. However, the final version should be reconfigured to comply with the preceding rules.
  • Try to split things up into Scenarios as much as possible.
    • Related Articles

    • Stay consistent in naming Cycle files, images and variables.

      Problem Teams that use differing names for core elements often encounter difficulties when reading other developer's Cycle tests. Solution Sticking to the following naming conventions will help add clarity and greater readability to Cycle projects: ...
    • Make Cycle Features easier for others to understand.

      Problem Even well written Cycle Features can sometimes seem unclear to a new user. Solution By including comments at the beginning of your Feature and within Scenarios, you can lay out all pertinent details for a reader without needing to use Cycle ...
    • Aligning terminal Steps with Operator behavior

      Problem My terminal-based Cycle Steps don't always perfectly coincide with the actions a human operator performs on their device. Solution There are 3 terminal Steps that can provide a clear picture of the business process and end user operation. ...
    • What happens when I import Feature Files that have Scenarios with the same name?

      Problem If multiple Feature Files that contain Scenarios with the same name are imported and then a Scenario with a name that exists in multiple files is executed, what will Cycle do?  Solution When multiple Feature Files are imported that have ...
    • Getting Started with Cycle 2

      Log In to Cycle Cloud In order to get started with Cycle 2, you will need to sign up for a Cycle Cloud account, and then download Cycle 2 from Cycle Cloud. The sign up process requires you to verify your email address. Please note, the email address ...