Skip to main content
Version: 2.29

Feature Organization

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 Scenarios and reusing Scenarios. There are a number of reasons to implement a modular approach to Feature File development with Cycle:

  • Reusability: Breaking functions up into their own Scenarios means that a given Scenario can be imported and reused across Feature Files. 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 Feature Files.
  • Maintainability: When software changes, tests need to change. It is much quicker to update one Scenario that is shared across Feature Files than to update each individual Feature File.
  • “Debugability”: When Feature File 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 File.
  • Readability: By reusing Scenarios, top-level Feature Files 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 File, for efficient importing and reuse by other functional Feature Files.

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 File can then be 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 Feature Header, 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 File). The Background (one per Feature File) 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 File). The After Scenario, which runs after each non-@wip Scenario in a Feature File, 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 File or Scenario running first to set up 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 File 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.