Problem

With multiple developers and testers working on the same Cycle project, it's a struggle to keep everyone up to date with the latest Features and Settings.

Solution

Using a shared repository such as Git or Subversion when developing features for a Cycle project adds many benefits.

1) Promotes Modularity - Cycle developers may develop re-usable datasets, utility scenarios, MOCA scripts, or SQL scripts that other developers on the same Cycle Project are able to utilize in their own scenarios. This reduces the amount of development time when one developer is able to leverage work previously done by another developer.

For example, one developer may write an msql script to allocate waves when writing a feature for pallet picking. Later, a different developer may need to allocate waves when writing a feature for case picking. A shared repository allows the second developer access the script written by the first developer reducing overall development time.

2) Version Control - Using a shared repository during Cycle feature development provides version control of features. Committing updated or enhanced versions of features with comments describing associated system config changes or enhancements incorporated into the feature allows for tracking changes to the features as the tested system changes over time. This also allows a Cycle developer the opportunity to compare the versions of the files they are uploading against previous versions before committing to ensure existing functionality is not overwritten or impacted by mistake.

3) Portability and Availability - Having a centralized repository available to all team members writing and running Cycle features gives developers access to the latest version of all features, datasets, utility features, scripts, etc... without the need to request and retrieve files from multiple team members or locations. A copy of the entire repository can easily be retrieved and a developer can begin using it immediately.

Files that do not need to be modified when running Cycle on different machines are the best files to version control in a repository. Developers can commit new versions of those files as features are developed, expanded, or enhanced to test system functionality, configuration changes, and modifications.

Cycle Projects

In version 2.2.0 and later, Cycle includes the Projects file structure. Cycle Projects help streamline the process of sharing Cycle tests and settings across a team.

When a new Cycle Project is created, a default set of directories is automatically defined to help keep different parts of the project clearly defined.

Some projects may call for additional or different directories to be created depending on what makes sense for the system the features are being developed for. However, the purpose of those directories will be similar to the directories listed below. There are some directories and files that provide challenges when using a shared repository, more info on these can be found below. 

• Datasets - Contains the load and cleanup files corresponding to the Feature.
• Files in this directory can be committed to a shared repository and are readily portable to other various machines to be used by multiple resources.

• Features – Contains the top-level Feature files used to execute Cycle automated tests
  • It is best practice to keep a version of the environment.feature in the repository that has variable placeholders instead of actual values for connection and user specific information
• MOST but not all files in this directory can be committed to a shared repository and are readily portable to other various machines to be used by multiple resources.
• An environment.feature file is typically stored in the Features directory. This file usually contains environment specific settings that need to be modified for different users (user name, password, device code, etc…) or when running features in a different environment (web URL, MOCA service connection string, MTF connection information, etc…)

• Features/Utilities - Subdirectory within the Features directory that has utility scenarios that are specifically for the environment in which the Features operate. These utility scenarios provide for modularity and re-use of common scenarios (RF menu navigation, workflow execution, Web UI navigation, common picking functions, etc…).
  • Files in this directory can be committed to a shared repository and are readily portable to other various machines to be used by multiple resources.
• Grouptests - Contains the .cvt files for any Group Tests established as a part of the Project.
  • Files in this directory can be committed to a shared repository and are readily portable to other various machines to be used by multiple resources.

• Images - This directory contains the images used for image matching in any features.
• Image matching is dependent upon resolution and other graphics settings to work properly. Issues may be encountered when running features developed on a different machine if the graphics properties do not match the original development machine.
• Suggested practice is to develop features to run on a test server in a Continuous Testing  environment. The images would be captured for image matching on that specific machine.
• Files in this directory can be committed to a repository, BUT it may be necessary to capture different versions of images to run on a specific machine for troubleshooting/feature development purposes.
• If different versions of images need to be captured for image matching on a machine that will not be running the features in the future, those specific images should not be uploaded to the repository overwriting the base images used by the Continuous Testing server. It is important to not overwrite the “golden” versions of the images that were captured for use on the Continuous Testing server.

• Playlists - Contains playlists of features grouped by functional area
• Files in this directory can be committed to a shared repository and are readily portable to other various machines to be used by multiple resources.

• Reports - Contains the reports generated by previously run tests within the project.
  • Files in this directory can be committed to a shared repository and are readily portable to other various machines to be used by multiple resources.

• Scripts – Folder for msql scripts utilized within scenarios
  • Files in this directory can be committed to a shared repository and are readily portable to other various machines to be used by multiple resources.

A few additional directories that may be useful in your project include:

• DataExtractModels -  This directory contains cycextract files used to extract data using the data extract tool within cycle
• Data extract files can be created to pull various types of data from the connected system (using JDBC or MOCA connections)
• Examples of data that may be extracted are master receipts, orders, shipments, inventory, and terminal devices
• Files in this directory can be committed to a shared repository and are readily portable to other various machines to be used by multiple resources.

• Interfaces - Contains xml files used by Integrator features
  • Files in this directory can be committed to a shared repository and are readily portable to other various machines to be used by multiple resources.

Not all files make sense to version control in a repository. Files that are modified to run Cycle features for a specific user, in a specific environment, or on a specific machine that need to be continuously modified should usually be ignored when committing updated files to the repository. The default Project template also contains a .gitignore file which can be updated to automatically stop Git repositories from tracking those files that are user specific. Most version control applications provide the ability to ignore files from tracking.

It is best to upload these types of files in the repository with variable placeholders than can be replaced with user/environment specific values on a user’s local machine as needed.

Using placeholder values in shared Features

The example below demonstrates using a placeholder “USERNAME” in a variable that assigns a value to the “username” variable

Ex: And I assign "USERNAME" to variable "username"

• This initial environment.feature can be downloaded to the user’s machine and updated to run for the user and environment being tested.
• The updated local version of the environment.feature should be ignored and not uploaded when committing changes from the user’s local repository to the shared repository,
• Any changes to the environment.feature that need to be present for all developers should be made to the version of the feature that has the placeholder values and that version should be uploaded to the repository.