Modules

Modules allow you to create reusable test sequences that can be shared across multiple test cases. This reduces duplication and makes your test suite easier to maintain.

What are Modules?

A module is a test case that can be executed as a step within other test cases. Common use cases include:

• Login flows - Reuse the same login sequence across all tests that require authentication
• Setup procedures - Common navigation or data setup steps
• Shared validations - Standard checks that apply to multiple scenarios

Creating a Module

1. Create a new test case with the common steps you want to reuse
2. Mark it as a module in the test case settings
3. Reference it from other test cases using the Module step

Any test case can be turned into a module. Once marked, it appears in the module picker when adding steps to other test cases.

Using a Module

To use a module in your test case, add a Module step and select the module to execute.

Configuration:

• moduleId (required): The ID of the module test case to execute

When the module step runs, all steps from the referenced module are executed in sequence before continuing with the rest of your test.

Step-by-Step Walkthrough

1. Open a test case where you want to reuse a workflow
2. Add a new step and select Module as the step type
3. Pick the module from the dropdown
4. The module's steps execute inline when the test runs
5. After the module completes, the next step in your test continues

Variable Sharing

Modules can set and use variables:

• Input: Variables set before the module step are available inside the module. Set environment variables or use earlier steps to prepare data the module needs.
• Output: Variables set inside the module (via window.setVariable() or Extract and Save steps) are available to all subsequent steps in the parent test case.

This makes modules flexible — a login module can save the logged-in username, and later steps can reference it.

Nested Modules

Modules can call other modules (a module step inside a module). However, keep nesting shallow:

• One level of nesting works well (Module A calls Module B)
• Deep nesting (Module A → B → C → D) makes debugging harder
• If you find yourself nesting deeply, consider restructuring your modules

When to Use Modules

Good candidates for modules:

• Login/authentication flows used in many tests
• Navigation to a specific page or section
• Data setup (creating a user, adding items to cart)
• Common verification sequences (checking a dashboard loads correctly)

Not ideal for modules:

• One-off workflows used in a single test
• Steps that vary significantly between test cases
• Very short sequences (1-2 steps) — the overhead isn't worth it

Best Practices

• Keep modules focused - Each module should do one thing well
• Use descriptive names - Make it clear what the module does (e.g., "Login as Admin" not "Setup")
• Avoid deep nesting - Modules calling modules can make debugging harder
• Share variables intentionally - Document which variables a module expects and which it sets

Benefits

• DRY (Don't Repeat Yourself) - Write common flows once
• Easier maintenance - Update a module and all tests using it are updated
• Consistent behavior - Ensure common flows work the same everywhere
• Faster test creation - Build new tests from existing building blocks