4.1 CertiBlocks™ Modular Sub-Routines (Zero Duplication)

How to author reusable parameterized sub-routines (OAuth login, checkout flows) and embed them across UI, API, and Agent tests.

Fifty Tests, One Login Flow

When 50 test cases all begin with the same 6-step login sequence, a change to that login flow – a new consent checkbox, an extra MFA prompt – means editing 50 places by hand, and it only takes one missed case for that suite’s coverage to quietly start lying to you. CertiBlocks exist to make that a one-time edit instead: build the login sequence once as a CertiBlock with its own input parameters ({{ username }}, {{ password }}), then embed it by reference wherever it’s needed. A CertiBlock reference holds only an id, a name, and a description – not a copy of the steps – so editing the source block changes what every case, suite, or agent test that embeds it actually runs, without anyone needing to open or resave those parent entities.

CertiBlocks aren’t scoped to one testing surface, either. A UI-driven “Standard Login” block built from CLICK and INPUT_TEXT steps can sit in the same block library as an API-driven “OAuth Token Exchange” block built from an API Request step – both are just named, parameterized step sequences a case can embed, regardless of which kind of steps they’re made of.

Building and Embedding a CertiBlock

• 1. Click “CertiBlocks” in the left navigation and click “+ New CertiBlock” – name it for what it does (e.g. “OAuth Login Block”), not for where you first needed it.
• 2. Author its steps like any other case, then mark the values that should differ per call site as input parameters ({{ username }}, {{ password }}) rather than hardcoding them.
• 3. From any Test Case, click “+ Add Step” -> “Embed CertiBlock” and pick it from the library – the embedded call site fills in its own values for each parameter without touching the block’s own definition.
• 4. Edit the CertiBlock itself later and every case, suite, and agent test embedding it picks up the change on their next run, with no need to reopen or resave any of them.

Naming a Block for the Next Person

• A case’s step list is meant to be scannable at a glance – a well-named block (“Stripe Checkout Block”, not “Setup Block”) lets a reviewer tell what’s actually running without opening it, the same way a well-named function reads better than one called doStuff().