Comparing Alternatives
Cycle effectively offers the following ways to make custom callable procedures:
When should you use one over the other? Let's compare:
| Reusable Scenarios | Groovy Scripts | Step Plugins | |
|---|---|---|---|
| Description | Procedures written directly in CycleScript feature files with existing steps. | Procedures written in the Groovy programming language and called from CycleScript steps. | New CycleScript steps added to the language. |
| Implementation Effort | Small | Medium | Large |
| Advantages | Logic is written directly in feature files. Does not require additional programming knowledge. | Handles more complicated logic that would otherwise be cumbersome or even impossible with regular CycleScript. Fits right into Cycle without extra dependencies. | Provides declarative, domain-specific steps that read more like plain language and avoid verbosity in reports. Can share state* between related steps. |
| Disadvantages | Limited to steps already available in CycleScript. Adds verbose logging to reports. | Requires Groovy programming skills to read and write. Cannot control shared state* as easily. | Requires web service development skills. API must conform to strict standards. |
| Recommended Use | Concise procedures whose operations can be written with existing steps. | One-off steps that require complex logic that CycleScript itself does not provide. | A set of related steps that are called frequently and share state*. |
* "Sharing state" refers to data or objects that different steps need to share between each other. For example, Web steps share a WebDriver session between them for making browser interactions. All Web steps need access to the same session so they can interact with the same browser.