Problem

Cycle Features can often require set-ups before a system is in the correct state to begin the test or cleanup after having run to return everything to a clean state.

Solution

Cycle includes the ability to use two special types of Scenarios called Background and After Scenarios that will run before and after each non-@wip scenario that is executed in a Feature.

Backgrounds and After Scenarios use the same Cycle steps that are used in regular Scenarios, but they give the Cycle Feature developer the ability to run similar steps before and after each Scenario in the Feature without duplicating those steps in each feature. Backgrounds are most useful to run any sort of environment setup or data prep steps before a Scenario is executed. After Scenarios are best served to run cleanups, validations, and special messaging.

The purpose of this article is to highlight how Background/After Scenarios are executed and some common suggested practices for utilizing them.

Examples

Background/After Scenario scenarios will run before and after any non-@wip scenario that is executed in the Feature. This means that any Scenario executed within a single Feature will run the same Background/After Scenario.

Also, it is important to understand that After Scenarios always run after a Scenario finishes executing. This means that the After Scenario will run even if a step within the regular Scenario fails.

From the attached example:

The Feature above contains a Background, an After Scenario, two Scenarios, and one @wip scenario.

The Background/After Scenario should be considered as globally applying to any Scenario that is run in the Feature. You cannot specify a Background to be run for Scenario 1 and a Background to be run for Scenario 2. Both Scenario 1 and Scenario 2 will run the Background “My Background” in the above example. Then both Scenario 1 and Scenario 2 will run the same After Scenario “My After Scenario”.

You can see that each Scenario runs the Background and After Scenario by drilling down into the output.

Scenario 1:

Scenario 2:

After Scenarios will ALWAYS execute after a regular Scenario regardless of whether or not a step fails in the regular scenario. For example, I intentionally failed a step in Scenario 1, but the After Scenario still executed:

It is important to note that the Background/After Scenario did not execute before and after the @wip scenario was executed. Background/After Scenario scenario types run only before and after regular non-@wip scenarios:

---

Commonly Used Steps in Backgrounds

The most commonly used steps/scenarios used in Backgrounds usually involve any sort of setup required to execute a scenario.

This could include but is not limited to:

• Environment data - connection strings, usernames, passwords, terminal device settings, etc…
• Data to be used by datasets - wh_id, client_id, login location, operation code, etc…
• Importing utilitity scenarios from other Features - scenarios from a picking utility feature to be used for terminal picking as an example
• Defining any assumptions that could help someone reading the Feature file understand the intention of the test and prerequisites for it to be executed

Below is a deeper dive into an actual Background Scenario pulled from a JDA WMS Bundle Library feature and a description of what is being done with each of the steps. The bundle library Features make extensive use of Backgrounds and are a good reference to understand their usage.

In the above example:

• Lines 30 – 32 import scenarios from related utility features using the “I import scenarios from <FILE>" step.
  • The Environment.feature includes utility scenarios for environment setup.
  • The Terminal_Utilities.feature and Picking_Utilities.feature include utility scenarios that are used by this feature to complete case replenishment in the terminal.
• Lines 33 – 36 execute imported scenarios and scenarios included within this feature to setup environment data, dataset variables, and establish connections
  • The scenarios for Local Data Override (line 33) and Local Data (line 35) are local to this feature and assign variable values. These values are assigned before executing the main Scenario that is run after the Background completes.
  • Scenarios to complete environment setup and export MOCA environment variables used by the main Scenario are executed on lines 34 and 35.
  • The “Set Up Environment” scenario establishes a MOCA connection in addition to assigning environment variable data.
• Any variables assigned in the Background are available for the Scenario to use
• Lines 37 – 45 are activity steps “I <ACTIVITY>” that do not actually execute a Cycle step but aid in documentation as they are written to the output
  • In this example, these activity steps are listing assumptions that were made during the writing of this feature.
  • For example, line 44 states the assumption that the dataset will create a case to fulfill the replenishment

Background scenarios are not limited to the usage as given in this article. You may also find there are instances where you can include dataset creation as part of your Background. This would be useful if every scenario in your Feature uses the same exact dataset with the same variables each time. However, scenarios usually require slightly varying data for each test case, and the dataset creation usually needs to be within the Scenario itself rather than the Background. In those instances, you will probably make slight changes to your dataset variables within the scenario and then run the dataset creation.

Commonly Used Steps in After Scenarios

The most commonly used steps/scenarios used in After Scenarios usually involve any sort of cleanup required after a scenario is executed.

This could include but is not limited to:

• Dataset cleanup
• Closing connections
• Logging out of systems
• Closing the web browser/killing web browser tasks
• Custom Messaging

Below is a deeper dive into a couple of After Scenarios included in the JDA WMS Bundle Library (one for an RF terminal-based feature and one for a web UI based feature).

In the above example:

• Line 48 is executing an imported scenario that is used during volume tests to lock pick work tasks to a device. This scenario was imported as part of the Background and is available for Cycle to use through the entire process all the way through the After Scenario.
• Lines 49 – 54 are use normal RF navigation steps to ensure the RF terminal is returned to the appropriate menu for the Logout scenario
• Line 55 runs the RF terminal logout scenario to ensure the terminal is properly logged off and connection closed
• Lines 56 – 61 execute the MOCA dataset cleanup if applicable

In the above example:

• Lines 66 – 69 execute MOCA dataset cleanup if applicable
• Line 71 – This executes the “Web UI Logout” scenario that was imported in the Background
• Line 72 – This executes the “Kill Web Driver Tasks” scenario that was imported in the Background
  • It is important to log out, close web browsers, and kill web driver tasks when working with web browsers otherwise web browser tasks may be left open and consuming system resources
  • It is always a good idea to handle closing of web browsers in After Scenarios rather than at the end of Regular scenarios because After Scenarios always run even if a step fails in the Regular scenario

Additional useful steps that might be included in an After Scenario are writing confirmations to the output or custom log file that a test passed or failed based on actions within the main scenario.

You may also run MOCA scripts in the After Scenario to validate that data is in a certain state based on the successful execution of the scenario. For example: you may be testing shipments going to “Load Complete” after a trailer is dispatched. You may include a validation msql MOCA script in the After Scenario to ensure the shipment status is correct after the Scenario executes. Validations may make more sense to be in the main scenario depending on the specific test case and layout of the file, but After Scenarios can be a good place to include validations when it makes sense.