Skip to main content

Creating New Steps

In addition to all its out-of-the-box steps, Cycle enables testers to create their own CycleScript steps with step plugins starting in Cycle 2.20.

Why should I create new steps?

For example, suppose you need to verify that your system sends a report with very specific codes in the header. You could write procedures in CycleScript to verify them using existing web, API, or file steps, but it would be much more readable and writable to create a new step like this:

Then I see the header code "X12345" in the Special Report file

This is a domain-specific step. It uses expressive natural language to denote the desired operation declaratively, rather than using imperative language involving string parsing or complicated locators. Domain-specific steps help testers separate what must be tested behaviorally from how automation will work mechanically. They also provide living documentation for the features they cover, since anyone (developer, tester, manager, or business stakeholder) can understand them. Furthermore, they enable you to create steps for any kind of system so that your tests can be truly "end-to-end."

How do step plugins work?

New steps are provided by "step plugins." A step plugin is a local service that extends Cycle with additional steps. It provides steps through an API in which a line of CycleScript step text maps to an API endpoint. For example, the reporting step above could map to a step plugin endpoint with the route POST /special-report/verification/header-code and request body { "header-code": "X12345" }.

When Cycle runs this step in a feature file, it would map the step text to this particular endpoint, call it with an HTTP request, and receive an HTTP response once the step has completed its execution. The callback function for this endpoint would need to perform whatever operations are required to handle the report file verification.

Ultimately, steps from a step plugin should work the same as any "regular" Cycle steps. They should be effectively indistinguishable in a feature file.

How do step plugins define steps?

All the steps, routes, and parameters are defined in an OpenAPI specification. All requests to step plugin endpoints use HTTP in accordance with the spec. Cycle uses a step plugin's OpenAPI spec for editing features (like syntax highlighting and step suggestions) as well as for mapping steps to step plugin endpoints during test execution.

How are step plugins plugged into Cycle?

Step plugins are plugins that extend Cycle. They can be installed into Cycle's installation directory together with some required settings. Cycle will automatically identify and use step plugins that are properly configured, and it will yield errors whenever it discovers problems with step plugins.

Who can create a step plugin?

Any Cycle user can create a step plugin and plug it into Cycle. In fact, certain out-of-the-box steps are implemented as step plugins! However, step plugins can be challenging to create because they require advanced skills. A step plugin developer will need testing skills for knowing what steps to make as well as development skills for knowing how to create web services with a complex OpenAPI spec. Step plugins may be implemented in any programming language with any web framework as long as they conform to all the requirements for proper pluggability.

How do I get started?

If you want to develop your own step plugin, please follow the steps below:

  1. Compare alternative solutions to make sure that a step plugin is the right approach.
  2. Determine the new steps to create.
  3. Pick the programming language and web framework to use.
  4. Write the OpenAPI spec for the steps.
  5. Use Cycle properties to pass special values from Cycle into step plugins.
  6. Implement endpoints for all the new steps.
  7. Implement required endpoints for the step plugin's execution lifecycle.
  8. Add the step plugin to Cycle.
  9. Resolve any plugin errors.

If your step plugin will contain several steps, then it may be best to implement steps in small batches. Implement a few steps at a time, plug the latest build into Cycle, and test the steps iteratively.