Use case

Test a signup and email-verification flow, end to end.

A new user registers, gets a confirmation email, clicks the link, and becomes a real account. That path crosses three protocols — HTTP, IMAP and LDAP — so a test that only covers the HTTP call leaves the rest unchecked.

Email verification is the classic flow that looks like one feature and is actually three systems shaking hands: an HTTP API, a mail server, and a directory. VirtuProbe Studio lets you drive all three from one chain — register, catch the email, follow the link, confirm the account — and turn "it worked when I tried it" into a test you can re-run and keep as evidence.

01The flow you actually need to test

Walk through what "verify my email works" really means:

An HTTP POST creates the user and triggers a confirmation email.
The mail lands in a mailbox you can only reach over IMAP.
The email contains a one-time verification link with a token.
Following that link flips the account to verified.
Only then should the account exist as something a directory (LDAP) will bind.

A test that stops at the HTTP call covers the first hop. Most of the failures that matter are downstream: the email never arrives, the token has expired by the time it's used, or the account registers but is never provisioned into the directory. Catching those means driving all three protocols in sequence and passing state between them.

02One chain, three protocols

In VirtuProbe a chain is an ordered sequence of steps. Each step runs a request, an extractor pulls a value out of the response into a named variable, and later steps reference it with {{variable}}. That's the whole trick: the token you extract from the email in step two is the token you replay in step three.

The verification flow lands as four steps:

# Chain: signup-verification

01  HTTP   POST /api/register
           extract  HTTP_JSON_PATH  $.id          → {{userId}}
           assert   HTTP_STATUS     EQUALS 201

02  IMAP   SELECT INBOX; SEARCH UNSEEN; FETCH 1 (BODY[TEXT])
           extract  REGEX  https?://\S+/verify\S+  → {{verifyUrl}}

03  HTTP   GET {{verifyUrl}}
           assert   HTTP_STATUS     EQUALS 200

04  LDAP   BIND uid={{userId}},ou=people,dc=example,dc=com
           assert   LDAP_EXCHANGE_RESULT_CODE  EQUALS 0

Step 1 — register (HTTP)

Send the registration request as an HTTP probe. Attach an HTTP_JSON_PATH extractor ($.id) to capture the new user's id into {{userId}}, and assert the status with HTTP_STATUS so a silent 500 fails the run instead of sailing through.

Step 2 — catch the email (IMAP)

An IMAP step selects the inbox, searches for the unseen message, and fetches its body. VirtuProbe implements IMAP against the RFC directly, so SELECT, SEARCH and FETCH are all first-class command types. To pull the link out of the body, attach a generic REGEX extractor to the same step and capture the URL into {{verifyUrl}}.

Honest note: there's no bespoke "grab the link from an email" extractor — you write the regex, which is the right amount of control when confirmation URLs differ per project. The regex above is a starting point; tighten it to your token format.

Step 3 — follow the link (HTTP)

A second HTTP step requests {{verifyUrl}} verbatim — the variable is resolved before the request is sent. Assert HTTP_STATUS EQUALS 200 (or a redirect, if that's your design) so an expired or malformed token is a failed step, not a shrug.

Step 4 — confirm the account exists (LDAP)

Finally, an LDAP step binds (or searches) for the freshly-created account and asserts the result code. Result code 0 is success; 49 is invalid credentials; 32 is "no such object" — the exact signal that registration happened but provisioning didn't. VirtuProbe implements LDAP from scratch (BER, RFC 4511), so you're asserting on the real wire response.

03Make it a real test, not a click-through

Clicking through the flow by hand proves it worked once. A chain proves it works every time and leaves something behind:

Assertions. ASSERT steps and per-step expected values (EQUALS, CONTAINS, MATCHES, GT/LT, …) turn each hop into a pass/fail gate. A failed assertion stops the chain where it broke.
Run history & diff. Every run is saved (the last 20 per chain), so you can compare a green run against the one that started failing and see which step's response changed.
Evidence, not screenshots. Export a run as JSON evidence — no re-run, no re-auth — for a ticket, an audit, or a teammate.
Variations. Wrap the chain in ITERATE to run it across a list of test users, or gate a branch with CONDITION when the flow forks.

Spinning up a throwaway stack to test against? A local GreenMail mail server is a common target here — note that GreenMail logs you in with just the local part of the address (test, not test@example.com). That's a quirk of the test server, not of the client — VirtuProbe sends exactly the login you give it.

04Why do it in VirtuProbe

Because the flow spans HTTP, IMAP and LDAP, and you can run all three from one place. Each protocol is a hand-written stack built against its RFC, so requests go on the wire the way you wrote them. Chaining carries state between steps without copy-paste, and everything runs locally — your requests, tokens and mailboxes stay on your machine.

Build the chain yourself. VirtuProbe Studio is free to download — no account, no cloud, no telemetry. Chaining, environments and request history are on the free tier; the full protocol suite unlocks per tier.

Download VirtuProbe Read the chains docs →