Steps Best Practices

  • Use in app, in web browser, in element, and in terminal Steps instead of generic Steps - affix your steps with the most specificity possible.

  • We advise using I wait and within clauses as sparingly as possible, defaulting instead to the Once keyword.

  • If an I wait step is necessary, use the I "<TEXT>" which can take between <NUMBER> seconds and <NUMBER> seconds step instead - as this is clearer for both maintainability and the resulting reports.

  • Use I execute scenario instead of inline scenario calls - external scenario calls become more evident with this approach.

  • Avoid declaring wait times inline - use Environment Variables instead.

Business/Activity Steps vs Comment Steps

Each logical chunk of CycleScript should be prefixed with a Business/Activity Step or a Comment Step.

A Business/Activity Step is a non-action step that uses I “<TEXT>” to describe a general action.

These steps should not be indented, and logical code chunks associated to them should be indented directly beneath them.


    Given I "check the inventory status"
        Given I "obtain the load number"
        And I "open a terminal"
        And I "navigate to the Undirected Menu"
        And I "navigate to the Inventory Menu"
        When I "filter by the load number"
        And I "grab the status from the screen"
        Then I "validate the inventory status"

As shown in the example, the logic associated to the Business/Activity Step is indented one level. This allows for CycleScript to map directly to work instructions - you can port work instructions line by line before writing a single functional piece of CycleScript.

There are some cases where the work instruction can have child logic of higher complexity. In this case, use Comment Steps, which use the same I “” step, but on an indented level.

You can think of a Comment Step as a programmatic comment to indicate what the subsequent chunk of CycleScript does.


    Given I "send a shipment to a customer"
        Given I "allocate the shipment"
            Given I "navigate to the allocation screen"
            And I "filter for the shipment"
            When I "allocate it"
            Then I "validate it is allocated"

        And I "pick the shipment"
            Given I "navigate to the Terminal Picking screen"
            When I "pick all the items"
            Then I "validate it is fully picked"

        When I "load the truck"
            Given I "navigate to the Loading screen"
            When I "place all items in the truck"
            Then I "validate all items are in the truck"

        Then I "dispatch the truck"
            Given I "handle all safety checks"
            Then I "send the truck off"

The use of Business/Activity Steps and Comment Steps makes CycleScript much easier to read and therefore more maintainable.

You can use the traditional CycleScript comments to denote other additional information as long as it’s not relevant to the generated report - but valuable to the developers maintaining and developing the code.

    # I chose to not include Undirected Putaway because the client
    # specified that that should never happen.
    # You can expand this branch by adding an extra 'Elsif' on line 32.

Business/Activity and Comment Steps are not necessary in Backgrounds, After Scenarios, Utilities, and external scenario calls if and only if the associated code blocks are simple and self-evident.

Here is an example of simple and self-evident code:

    Given I execute scenario "Allocate Wave"
    And I execute scenario "Validate Pick Release"
    When I execute scenario "Perform Pallet Picking"
    Then I execute scenario "Validate Pick Completion"

results matching ""

    No results matching ""