Overview
The Run Python step lets you execute custom Python code within a test with full Playwright access. Use it for complex logic, validations, data processing, and API/UI cross‑checks.Note
- Do not use double braces
{{ }}
inside this step. Instead,env
,vars
, andrandom
are provided directly as in‑memory objects.env.NAME
is read‑only,vars.name
(aliastestVars.name
) contains values produced by earlier steps, andrandom.*
provides generators.
Execution model
- Wrap code in
async def supatest_run_code(...):
- Runs in the test’s browser context with Playwright available; always
await
async calls - Optional inputs come from selected variables; the function’s
return
value is saved to a named variable - Uses the step timeout; prefer explicit waits over fixed delays
print()
output appears in Raw Logs; failures include stack traces when available
Capabilities and globals
Available during execution:- Playwright:
page
,expect
- Networking:
fetch
(JSON/ArrayBuffer) - Supatest:
env
,update_env(name, value)
,vars
(aliastestVars
),random
Environment variables
env.KEY
is a read‑only view of the selected environment at the start of the run.update_env(name, value)
persists changes to existing variables in the selected environment (org‑scoped).- Missing or failed updates cause the test to fail.
- Raw Logs show per‑call queued updates and one final summary.
When to use
- Conditional validations, loops, data transforms
- Compare UI state with API responses
- Temporary workaround when no dedicated step exists
Usage (form + editor)
- Title: short, descriptive
- Code: write inside
async def supatest_run_code(...):
with Monaco editor syntax highlighting - Variables (optional): select earlier variables to become function parameters
- Return variable (optional): name for
return
value to use in later steps - Timeout (optional): override default
AI code generation
- Prompt in plain English; code respects Playwright best practices
- Refine with follow‑ups; review and edit before running
Examples
Minimal examples you can adapt:Basic page interaction
API and UI comparison
Using env, vars, and random (no {{ }}
required)
Download file and parse CSV
Best practices
- Structure: single entry
supatest_run_code
, return only what later steps need - Selectors: prefer stable attributes; avoid brittle position‑based locators
- Waits: use Playwright waits (visible/attached/navigation) instead of fixed timeouts
- Assertions: prefer
expect(...)
over manual checks - Performance: keep code concise; minimize unnecessary DOM queries and network calls
Common issues and fixes
- Not wrapped in
supatest_run_code
→ wrap all logic inasync def supatest_run_code(...):
- Missing
await
→ await Playwright and promise calls - Return value not saved → set a Return variable name and ensure you
return
it - Timeouts → add explicit waits or increase step timeout
- Unreliable selectors → use more specific, stable attributes (e.g., data‑testid)
Third Party Libraries (Python)
- Database (PostgreSQL): Use
asyncpg
for async Postgres access from your test code. - CSV parsing: Use built‑in
csv
withaiofiles
for async I/O and streaming‑friendly parsing.
Example: Query PostgreSQL with asyncpg
Example: Parse CSV from API using aiofiles + csv
Example: Stream parse a local CSV file using aiofiles
We will expand this list over time with additional approved Python libraries.