Testing

Comprehensive guide to SolidX testing architecture, workflow, vocabulary, and execution.

Mental Model

SolidX testing is a single metadata-driven system with multiple execution modes.

testing metadata defines fixtures, custom specs, users, roles, and scenarios.
The workflow prepares the system under test through setup, seed, load, run, and teardown.
The engine executes api, ui, and mixed scenarios through shared runtime primitives.

The important distinction is that API testing and UI testing are different adapters on top of the same testing model, not two unrelated frameworks.

SolidX provides a metadata-driven testing system that supports:

Automated API testing.
Automated frontend end-to-end testing using Playwright.
Shared assertions and utility steps.
Managed test data setup and teardown.
CLI-driven workflows for bringing the application into system under test (SUT) mode.

The important idea is that API and UI tests are not treated as two unrelated systems. They run through a shared testing engine and a shared scenario model, while using different adapters underneath.

What This Section Covers

Architecture

Understand how the engine, adapters, step registry, runtime context, and reporter fit together.

Workflow

Follow the operational sequence for setup, seeding, fixture loading, execution, and teardown.

Vocabulary

Learn the terms used across scenarios, runtime primitives, and testing operations.

Authoring Scenarios

Write testing metadata, structure scenarios, and compose reusable steps.

API Testing

Use the API adapter, shared assertions, and response-driven workflows effectively.

UI Testing

Use Playwright-backed UI automation inside the shared SolidX testing engine.

Read This In Order

If you are new to SolidX testing, the best reading order is:

What SolidX Testing Looks Like In Practice

A typical test run looks like this:

Create isolated test datasources with solidctl test data --setup.

Seed metadata into the fresh databases with solidctl seed.

Load test fixtures, roles, and users from module metadata with solidctl test data --load.

Run API and/or UI scenarios through the shared testing engine.

Tear everything down and restore the original environment with solidctl test data --teardown.

At runtime, the testing engine:

Loads testing.scenarios from module metadata.
Filters scenarios by id or tag.
Registers built-in API, UI, assert, util, and custom spec steps.
Interpolates environment variables, params, test data, and saved resources.
Executes each scenario through the shared engine.

Where Testing Configuration Lives

Testing support is declared in module metadata under the testing key. That metadata can contain:

specs for custom test spec registration.
roles and users for testing-oriented identity setup.
data for test fixtures.
scenarios for executable test flows.

Operational Entry Point

The operational entry point for testing is solidctl.

The main commands you will use are:

solidctl test data --setup
solidctl seed
solidctl test data --load
solidctl test run --module <module-name>
solidctl test data --teardown

For the command reference itself, see solidctl Reference.