Start your 30-day trial.

1Install veriCue

curl -sL https://dl.vericue.dev/try.sh | bash

Downloads a demo Qt app plus the veriCue client into ./vericue-try/, drives it live, and leaves a screenshot on disk. No Qt install and no compiler needed.

curl -sL https://dl.vericue.dev/install.sh | bash -s -- --qt 6.7

Or download the tarball or zip for your platform and Qt major version directly from dl.vericue.dev and verify the published SHA256 - see Installation.

pip install vericue

C# teams: dotnet add package VeriCue. The C++ client ships inside the same archive as the Runtime library.

2Start the veriCue Runtime in your app

Link the veriCue library and start the Runtime in main(). The class you call is VeriCueServer. Because you never call setLicenseFile(), it enters trial mode by itself.

vericue::VeriCueServer server;
server.startLocal();   // no setLicenseFile() -> trial starts
qInfo() << server.localEndpoint();

The Runtime prints the endpoint it listens on, for example /run/user/1000/vericue/vericue-4213.sock - a user-private UNIX socket with no network presence, and the right default when the test client runs on the same machine.

vericue::VeriCueServer server;
server.setAuthToken("s3cret");
server.start(4242);    // or start(0) to let the OS pick

Local IPC is not available on Windows yet, so TCP is the supported local transport there. Pass 0 to let the OS pick a free port and read it back with serverPort(). A TCP port is reachable from other hosts: always set an auth token outside a single-developer machine. Both transports are compared in Transports: local IPC vs TCP; integration details in Embedding the server. Ship the Runtime in test and CI builds only.

# Linux - local IPC by default
vericue run ./your-qt-app
# VERICUE_ENDPOINT=/run/user/1000/vericue/vericue-4213.sock

# Windows - TCP
vericue run --port 4242 .\your-qt-app.exe

vericue run ships with the Python client from v0.5.0 and starts an unmodified Qt binary with the Runtime already inside it. Same command and same flags on both platforms; the mechanism underneath differs and it picks the right one for you. vericue-inject is that mechanism on Linux and stays usable directly, but it is a backend, not the command to learn.

The compatibility envelope is checked before anything launches, and every refusal names the cause and the fallback. Supported: a dynamically linked Qt whose major version matches the package you downloaded, on Linux x64 or Windows x64. Refused: static Qt, macOS, other architectures, hardened or setuid processes, launcher scripts, and - on Windows - a Qt that is only delay-imported. In those cases you link the Runtime in instead; veriCue code runs inside the target process either way.

On Windows, before you rely on it: the transport is TCP only - named-pipe local IPC is not implemented. The launcher loads the Runtime into a suspended process, which is a code-injection pattern that antivirus and EDR products may inspect or block; we make no claim of universal compatibility. The Windows binaries are not code-signed yet, so expect an unknown-publisher warning and verify the published SHA256 instead. See the Windows guide and Running an application.

3Run your first test

Connect, find an object, drive it, assert. That is the whole loop.

from vericue import VeriCueClient

async with VeriCueClient() as c:
    # Same machine - the endpoint the app printed:
    await c.connect_local(endpoint)
    # Across hosts or containers, and on Windows:
    # await c.connect("10.0.0.5", 4242)
    await c.mouse_click("MainWindow/okBtn")
    props = await c.get_properties("MainWindow/statusLabel", ["text"])
    assert props["text"] == "Logged in"

Full walkthroughs: Python, C++, C#. Pytest fixtures, a GoogleTest fixture and Robot keywords ship with the clients.