Modules
Give tests controlled access to credentials, one-time codes, test cards, and email.
Modules attach secret or stateful capabilities to your tests without putting the values in the test text. You create a module once, and the agent uses it whenever a step needs it.
Module kinds
| Kind | What it provides |
|---|---|
| Login | A username and password for signing in to the site under test. |
| Payment card | Card details for test-environment checkouts. |
| MFA (TOTP) | Rolling one-time codes generated from a TOTP secret, for testing MFA login flows. |
| Custom secret | Any named value your flow needs, such as a coupon code or bypass token. |
| Email inbox | A receiving inbox the agent can read, for sign-up confirmation and magic-link flows. |
How the agent uses them
Reference the capability naturally in a step: "Sign in with the test account", "complete checkout with the saved test card", "enter the one-time code", "open the confirmation email and follow the link". The agent pulls the value from the attached module at the moment it needs it.
Security
Module values are encrypted at rest and are only decrypted to execute the tests you configure. Secret values never appear in the audit trail or in run output; you can delete a module at any time. Store only credentials for accounts and systems you are authorised to use, and prefer dedicated test accounts over real ones.
Session recordings show your application as the agent saw it. If your app displays a secret on screen after entry, that screen appears in the recording, so keep test credentials scoped to disposable accounts.