Modules

Write a flow once and call it from every test. Module definition, CALL, parameters, and the limits that apply to them.

A module is a named script fragment called from any test with CALL. A flow repeated across tests — login, choosing a city, setting up an address — is written once as a module.

Platforms	Android · iOS
Define with	# BEGIN <name> … # END <name>
Parameters	PARAM <name> in the body, CALL name(param={{value}}) at the call site
Nesting	Allowed. Cyclic calls are rejected
Watch out	After typing CALL, pause for the dropdown — typing straight through outruns it

Prerequisites

• Drizz desktop app installed and signed in

• A project to hold the module file

• A dataset bound to the plan, for any {{variable}} the module body references

Copy this

The module, saved as its own file:

# BEGIN shopease_login
OPEN_APP {{app_package}}
Wait Until 5 Seconds

Type {{phone}} in the mobile number field
Tap on Get OTP
Wait Until 2 Seconds

Type {{otp}} in the OTP field
Tap on Continue
Wait Until 5 Seconds

Validate that the home screen is visible
# END shopease_login

The test that uses it:

# T04 — ShopEase: search and add to cart

CALL shopease_login

Tap on the search icon
Wait Until 2 Seconds

Type running shoes in the search field
Tap on the first search result
Wait Until 3 Seconds

Validate that the product detail page is visible

Tap on Add to Cart
Wait Until 2 Seconds

Validate that Item added to cart is visible

CLEAR_APP com.shopease.android

Create and call a module

1. Create a script file for the module.

2. Save<Select Module

3. Name the module in snake_case, for what it does — shopease_login, city_selection_from_home.

4. Open the test that needs it and type CALL on its own line.

5. Pause for the module dropdown, then select the module by name.

6. Run the test and confirm the module's steps appear in the report.

Anything valid in a test is valid in a module, including IF blocks, Validate and other CALLs. A module doesn't have to start with OPEN_APP — a module that picks a city or dismisses onboarding doesn't launch the app.

CALL forms

Form	Written as	Behavior
Plain call	CALL shopease_login	Runs the module body in place
Parameterized call	CALL shopease_search(term={{food}})	Binds each named argument to the matching PARAM before running
Nested call	A CALL inside a module body	Allowed to any depth. Cyclic calls are rejected

The module's body appears inlined under the call line in the editor, indented and read-only:

CALL shopease_login
  # BEGIN shopease_login
  OPEN_APP {{app_package}}
  Wait Until 5 Seconds
  Type {{phone}} in the mobile number field
  # END shopease_login

Behavior of the inlined block	Detail
Editable	No. Edit the module file and every caller updates
Enter at the end of the call line	Jumps past the block, so typing continues in the calling script
Deleting	Removes the whole block as a unit. It can't be half-deleted
At run time	Drizz collapses the expansion before running, so the module executes once, not twice

Parameters

SET food = "Burger"
CALL shopease_search(term={{food}})
  # BEGIN shopease_search
  PARAM term
  Tap on the search icon
  Type {{term}} in the search field
  # END shopease_search

Element	Rule
Declaration	PARAM <name> on its own line, immediately after # BEGIN
Reference in the body	{{name}}
Argument at the call site	Named: CALL shopease_search(term={{food}})
Autocomplete	Selecting a module inserts its parameter signature with the caret in the first slot
Passing semantics	By value. A module that assigns a variable does not change the caller's copy. A module that sets total internally leaves the caller's total untouched after the call returns

Rules and limits

Rule	Detail
Naming	snake_case, for what the module does. Not T01_module
Scope	One purpose per module. A module that logs in and navigates forces the next caller to copy it to get half of it
Nesting	A module can call another module. Cyclic calls, which would loop forever, are rejected
Definitions	Every CALL needs a matching definition. Deleting the project that holds a module breaks every test calling it, and the warning is weak
Autocomplete lag	Type CALL, then pause for the module dropdown. Typing the name straight through outruns it and produces a CALL that looks right but isn't linked
Not a module	A single Tap. The indirection costs more than it saves
Not a module	A popup that can appear anywhere. Those go in Memory once and need no step in any script

Common mistakes

What you write	What happens
CALL shopease_login typed fast, no pause	The dropdown never fires and the call isn't linked to a module
Editing the inlined block under a CALL	It's read-only. Edit the module file
# BEGIN login … # END shopease_login	Names don't match — the module won't parse
A module that calls itself, directly or via another	Rejected as a cyclic call
Deleting the project that holds a shared module	Every test calling it breaks, Drizz warns you and blocks deletion until modules are resolved.
PARAM term halfway down the body	Declare parameters immediately after # BEGIN
Expecting a module's SET to change the caller's variable	Parameters and variables are pass-by-value. It won't
One module that logs in and navigates to checkout	The next test needs half of it and copies the whole thing

Next

• The shape of a test

• Which variable do I use?

• Memory & blockers

---

Last updated: 6 August 2026