Aligning terminal Steps with Operator behavior

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. Using these three steps correctly will lead to increased efficiency and readability. They also allow for your Features to be used as process documentation.

 

I type "<TEXT>" in terminal

This Step does precisely what it says. It types the specified characters in the terminal. This Step is intended to replicate when the Operator is using the terminal’s keypad for input. If the input field requires an ENTER to proceed on the form then this Step needs to be followed with the I press keys ENTER in terminal Step. Other instances, Y/N prompts for example, do not require a succeeding ENTER.

Example:

Given I type "SUPER" in terminal

Then I press keys ENTER in terminal

 Or

 Given I type “Y” in terminal

 

I enter "<TEXT>" in terminal

This Step combines the I type... Step with the I press keys Enter Step. It is intended to efficiently type text and proceed to the next field or screen. That might be the best approach when building Features depending on intent. Using this will help reduce the number of Cycle Steps when typing and entering is required from the Operator. However, this Step isn’t always indicative of the actual process the Operator follows since there is no configuration that will auto-enter after an Operator types in a terminal.

Example:

Given I enter "SUPER" in terminal

 

I scan "<TEXT>" in terminal

Functionally, this Step performs identically to I enter "<TEXT>" in terminal. The difference between the two centers on readability for process documentation. This Step is intended to replicate the process of an Operator scanning a barcode with their terminal. Most terminals are configured to automatically add an ENTER following a scan so that is exactly what this Step does. This Step accurately reflects what the Operator on the floor will do while also performing efficiently in the Cycle Feature. It should be clear to the reader of a Feature file what is happening on the floor when this Step is used.

Example:

Given I scan "LPN00123" in terminal

    • Related Articles

    • Structuring Feature files.

      Problem With multiple developers writing tests on the same project, inconsistent Feature File structure can lead to overlaps in test coverage and reduce test readability. Solution Adopting a modular approach Many common computer interactions are ...

    • 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 ...

    • 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: ...

    • How to Disable Terminal Beeps

      Depending on your system under test, you may hear terminal beeps (or bells) while executing terminal tests in Cycle. This article describes a solution for silencing terminal beeps. The Cycle application does not have a sound setting itself, however, ...

    • How to make better xpaths for web tests.

      Problem My web-based steps in Cycle are not finding the elements I want them to, or finding the wrong elements and giving me false-positives. Solution When possible, it is best to define elements to interact with on a web page by a static value that ...