Projects, tests & modules

How the file explorer organizes work — tests, modules, folders, the green M badge, and the Online/Local toggle.

A project holds two file types — tests and modules — organized into folders in the file explorer.

At a glance

New File → Test · Module · Folder

File types	Test — one end-to-end flow Module — reusable steps called from tests
Telling them apart	Modules carry a green M badge in the file explorer
Workspace	Online syncs with your org · Local shows drafts on your Mac
Scope	Everything is org-scoped — your colleagues see the same tests and modules
Watch out	Deleting a project that holds a module breaks every test that calls it, Drizz warns while taking this action. Resolving modules is the way out.

Prerequisites

• Drizz desktop app installed and signed in

• A project in your organization

File types

	Test	Module	Folder
Contains	One end-to-end flow, one step per line	A block of steps called from many tests	Tests, modules and other folders
Badge	None	Green M in the file explorer	Folder icon
Edited in	The editor	The editor	—
Runs	Locally on a connected device, or in the cloud through a test plan	Only when called from a test	Not runnable
Supports	Validations, conditionals, scrolling, system commands, module calls	The same commands as a test	Expand and collapse
Called by	—	CALL <module_name>	—
Functional effect of nesting	None — a test in a folder behaves the same as one at the root	None	Organization only

Full module syntax, parameters and nesting rules are on Modules.

Calling a module

CALL login_module

The module's body appears inlined beneath the call, indented and read-only. Edits are made in the module file, not in the inlined copy.

Naming conventions

Item	Convention	Example
Test	The flow's purpose, prefixed with an ID	T01 — Invalid search feedback, not test1
Module	What it does, in snake_case	login_module, city_selection_from_homepage, not T01_module
Folder	Feature, sprint or team	—

Online and Local

View	Shows
Online	Files synced with your organization's project — what your colleagues see
Local	Drafts and locally stored files on your own Mac

Test plans run what is Online. A file left in Local does not run in the cloud.

Sharing and module dependencies

Your organization is created automatically from your email domain. Tests, modules, folders, datasets and Memory are all org-scoped and visible to every member.

A module is a dependency of every test that calls it:

Action	Effect
CALL with no matching module	The step fails
Deleting a project that holds a module	Every test calling that module breaks. The warning is easy to miss
Renaming a module	Every CALL using the old name gets auto updated, editing modules applies changes to all test where that module will be called in future.

Creating a file

1. Click New File.

2. Select Test, Module or Folder.

3. Name it per the conventions above.

4. Confirm it appears in the file explorer tree.

Common mistakes

What you do	What happens
Delete a project to tidy up	Every test calling a module in it breaks, and the warning is easy to miss
Name tests test1, test2	Unreadable at 40 files. Name them for the flow
Edit the inlined module body under a CALL	It's read-only. Edit the module file
Type CALL login_module straight through	Autocomplete lags. Type CALL, pause for the dropdown, then pick
Assume your files are private	Everything is shared with your organization
Leave work in Local and expect a cloud plan to run it	Test plans run what's Online. Sync it

Next

• Modules

• Tour of the interface

• The shape of a test

---

Last updated: 6 August 2026