Blocks

Save a group of steps once, reuse it across every test that needs it, and fix it in one place.

Basic plan and above
View as Markdown

Almost every test on a real product starts the same way: accept the cookie banner, log in, dismiss the welcome modal. Copying those six steps into thirty tests works right up until the login form changes, at which point you have thirty tests to fix. A block is that group of steps saved once, referenced everywhere, and edited in a single place.

  1. 1The block family, Web or API. A block can only be used by tests of a matching type.
  2. 2How many steps expand in place when the block runs.
  3. 3Variables the block’s steps reference. The test always wins on a name clash.

Creating one

Open Blocks in the sidebar and create one, or select steps in a recorder and save them as a block. A block belongs to a family, either Web or API, and can only be used by tests of a matching type, because the two step vocabularies are different.

Using one in a test

Add a Block step wherever the sequence belongs. At run time the block expands in place and its steps execute as if you had written them inline, so a run report shows the individual steps rather than an opaque single entry. If you later want to break the link and edit the steps for this test only, unpack the block step and it becomes ordinary steps.

Limits worth knowing

  • Blocks do not nest: a block cannot contain another block.
  • A block cannot return a value to the test that used it.
  • A block can carry default values for the variables its steps use, but the test always wins on a name clash, which is what lets one block serve many tests.

Editing a block changes every test that references it. That is the benefit, and also the thing to be careful about before a big edit.

Still stuck, or spotted something out of date?

Contact support