Test data in DoesQA

Value Store, built-in dynamic Values, API steps, and external mock servers for test data and backend setup in DoesQA.

DoesQA brings Values, the Value Store, and Integration API steps into the same Flow as your UI steps. Generate realistic user data, share environment config, and call your APIs to prepare a journey without a separate fixture library.

The most reliable tests use data from a working backend. The browser exercises your application while Integration steps create and verify state on real HTTP endpoints in the same Flow. When a third party must return canned responses, point Integration steps at Mockoon or WireMock and store the base URL in a Value.

At a glance

You need

DoesQA approach

Names, emails, numbers in forms

Built-in Values ($testFirstName, $randomNumber, …)

Shared secrets and environment URLs

Account Values under Assets → Values

Data that changes during the Test Case

Value Store at runtime (Store, Set, Calculate, …)

Create or check backend state before UI

Integration API steps (GET, POST, PUT, PATCH, DELETE)

Canned responses from a third party

Mockoon or WireMock + Values for its base URL

Unique inbox per Test Case

$testEmail and Mail Test Steps

Heavy reliance on mocked responses can drift from production behaviour and add flake. DoesQA keeps setup on Values and API steps against your test environment so UI steps use data that matches what the application actually serves.

Built-in Values

Built-in Values generate realistic test data when you type $ in supported fields. The output is similar to what libraries such as Faker produce for names, emails, and numbers. Built-ins are native to DoesQA: pick a Value from the list when you build the Flow.

Two rules matter for every Flow:

Prefix

Behaviour

test*

Same value for the whole Test Case (for example $testEmail, $testFirstName)

random*

New value each time you reference it (for example $randomNumber, $randomEmail)

$randomEmail addresses use @mock.does.qa for form fill. For registration and mail journeys use $testEmail, which opens a real Test Case inbox.

Full lists and examples: Built-in Values.

Account Values every test can use

Create shared data under Assets → Values:

String for URLs, usernames, tokens
Number and Boolean for flags and limits
Object for JSON fixtures (feature flags, default payloads)

Overwrite Values per environment with Run Recipes, Start Run, CI/CD, or DoesQA Run. See Run across environments and Value Store for which source wins when names match.

Value Store as in-Flow fixture memory

During a Test Case, Data steps write to the Value Store. Common patterns:

Store element text, attributes, cookies, or storage into a named key
Set Value to build or overwrite data mid-journey
Calculate or Replace to transform stored text
Check Value Store or Check JSON Value to assert

Captured data stays available for the rest of that Test Case under the name you chose.

API steps in the same Flow

Integration API steps call HTTP endpoints from the hosted runner. Typical pattern:

POST to create a user or order. Set Response Storage Name to createdUser.
Open the app and fill the UI using $testEmail or fields from the stored response.
GET or Check JSON Value to confirm backend state.
DELETE to clean up when the journey finishes.

Walkthrough: Test APIs in a Flow. Setup and teardown patterns: Seed and clean up with API steps.

Fields inside stored JSON

When a step stores a JSON body, the Value is an Object. Later steps can use:

Dot notation in supported fields, for example $createdUser.id in a URL or text field
{{storageName}} in JSON bodies and headers for a whole stored Value
Check JSON Value to assert part of the response
Set Value to copy a nested field into a simpler name you reuse often

Pass tokens in Headers on the Integration step when the backend requires them.

External mock servers (Mockoon, WireMock)

For dependencies that need canned JSON, run Mockoon or WireMock and store its base URL in an Account Value such as $MOCK_API_URL. Point Integration step URLs at that host, or point your application's API URL Value at the mock for test builds configured that way.

DoesQA calls the mock like any other HTTP API. You maintain stub definitions in the mock tool. Guide: Use mock servers with DoesQA.

Feature

Use for

Block Hostnames

Control which third-party hosts load in the browser

Set Header

Add headers on the browser session

Generate File

Upload files with {{value}} in JSON contents

HAR recording

Review browser network traffic after a Run

One Flow for data and UI

Dynamic data, shared config, and API setup live in the same product as the browser steps. Values and Integration steps prepare the journey; the UI path runs on the data your backend (or mock server) returns. For third-party dependencies, pair DoesQA with Mockoon or WireMock and keep stub definitions in the tool your team already uses.