Parameterizing tests

The mechanism behind parameters is covered in Parameters & $placeholders. This page is the practical guide: how to design parameter names, where to put them, and how to feed values in.

Pick parameter names you can read

Mavster doesn't enforce naming conventions, but the test reads better when you do. A few practical rules:

• One concept per name. email is good; userInput1 is not.
• Lowercase or snake_case, consistent across the project. $email, $plan_id, $amount. Avoid $Email and $email in the same test (they're different parameters and the alphabetical parameter list will read confusingly).
• No leading digits. Names must start with a letter or underscore — $1stItem is not a parameter, just literal text.
• Escape literals with $$. Write Price is $$50 to have Mavster substitute Price is $50.

Where parameters live

Substitution scans:

• The test name.
• Every step's instruction.
• A Scroll step's Until field.

Anything else (mode pickers, run counts, region settings) is not scanned. If you need a parameter to flow somewhere not in this list, route it through the instruction of the relevant step.

Designing a parameterized test

A pattern that works well:

1. Author the test with literal values first ("test@example.com", "hunter2"). Get it green.
2. Replace the literals with $placeholders ($email, $password).
3. Confirm Mavster's parameter list shows the names you expect (the editor surfaces these as parameter slots).
4. Author a parent test or a User-Defined instance that supplies values via arguments.

Feeding values

Two paths.

Run Test

A Run Test step has an arguments dictionary. Set the values for the called test's parameters and Mavster substitutes them at run time.

Multiple Run Test steps in the same parent test can each supply different arguments, giving you a data-driven matrix:

Step 1: Run Test (signup, Run Count = 1, arguments = email: alice@example.com, plan: free)
Step 2: Run Test (signup, Run Count = 1, arguments = email: bob@example.com,   plan: pro)
Step 3: Run Test (signup, Run Count = 1, arguments = email: carol@example.com, plan: enterprise)

User-Defined instance

A User-Defined instance has its own arguments dictionary. Whatever you set on the instance is applied to its embedded steps when the instance runs.

This is the right path when the parameterized sequence is a building block (a "fill the credit-card form" template) rather than a standalone test.

Substitution timing

Values are substituted once, before the test starts running. Changing an argument mid-run has no effect on the in-flight test. Run history and costs stay attributed to the source test, not to a per-call copy.

Common patterns

• Credentials matrix. $email / $password parameters; one parent test calls the same signin test multiple times with different argument sets.
• Localized assertions. $welcomeText parameter on a Visual Assert; supply the right localized string per locale via Run Test arguments.
• Plan-tier coverage. $plan parameter on a sign-up test; one Run Test per tier in the parent.