Early access · No Tcl · No FlexLM · No enterprise-sized pricing

Qt test automation,
finally without the pain.

Drop a 600 KB server into your Qt 5 or Qt 6 app. Drive it from Python, C++, or .NET with 42 commands over an open TCP protocol. Sub-millisecond. Headless-CI friendly. No vendor lock-in. Professional needs no license server; Enterprise floating uses a self-hosted one inside your network.

Get a 30-day trial Read the docs

Commands

<1ms

Latency

Client SDKs

Qt majors

Try it now

From zero to a scripted Qt app in 5 minutes.

One command downloads a self-contained demo app (no Qt install needed), drives it live from Python, and leaves a screenshot on your disk. Linux x86_64 - other platforms start at installation.

terminal

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

Already have a Qt app? Evaluate against your own unmodified binary - no build changes:
vericue-inject --port 4242 -- ./your-qt-app how it works →

Why veriCue

The Qt testing tool you'd build yourself - if you had a year.

Six things that decide whether a test framework actually works in production.

Sub-millisecond protocol

Length-prefixed JSON over TCP. No browser engines, no DOM inspectors, no 30-second startup. Commands land in microseconds.

Widgets and QML, same API

Auto-detects QWidget windows and QQuickWindows. Same 42 commands work against both - including model/view data, touch, and gestures.

Built-in visual regression

Capture per-widget screenshots, diff against a baseline with configurable tolerance. Fails the CI when a button moves 3 pixels - not when it's noise.

Three first-class SDKs

Python (asyncio), C++ (Qt signals/slots), and .NET 8 (TAP). One protocol, three identical surfaces. Use whichever your team already knows.

Headless CI, on every push

Runs under QT_QPA_PLATFORM=offscreen. JUnit XML + HTML reports. Drop into Jenkins, GitHub Actions, GitLab CI - no display server required.

Open wire protocol

Documented JSON-over-TCP. Write a client in any language. Your test infrastructure stays yours - no Tcl, no proprietary scripting language, no lock-in.

For teams who tried the alternatives

"Why not just use…"

An honest take. Every team we talk to has tried at least one of these. Here's where they hit the wall.

Established commercial frameworks

Legacy GUI testing tools

Proprietary scripting from the 2000s
Licence-server daemon in CI
Four-figure renewals for every named tester
Heavy hook injection into the host app

Browser tools

Selenium & Playwright

Cannot see Qt widgets or QML items
Built for the DOM - wrong target
Slow test startup

Built into Qt

QTest framework

White-box unit testing only
Tests live next to the code, not the UI
No external CI driver, no recording

You'd actually use this

Open TCP protocol - write a client in any language
Python, C++, .NET ship today
Headless CI - QT_QPA_PLATFORM=offscreen
Transparent public pricing from EUR 299/quarter - see pricing

Drop-in API

Write tests in the language your team writes the product in.

Same protocol surface across SDKs. Pick the language that matches your CI and your developers' muscle memory.

Async-native APIs (asyncio, signals/slots, Task)
Push events via subscribe - no polling, no busy-waits
Pytest fixtures, GoogleTest fixture, Robot keywords ship with the client
Multi-process testing with MultiVeriCueClient

from vericue import VeriCueClient

async with VeriCueClient() as c:
    await c.connect("127.0.0.1", 4242)

    # Inspect
    btn = await c.find_object(path="MainWindow/okBtn")
    assert btn["className"] == "QPushButton"

    # Drive
    await c.mouse_click("MainWindow/okBtn")

    # Subscribe to a signal - push events
    sub = await c.subscribe_signal(
        "MainWindow/uploader", "finished",
    )
    event = await c.next_event(timeout=10)
#include <vericue/gtest_fixture.h>

class LoginTest : public vericue::VeriCueTest {};

TEST_F(LoginTest, OkButtonClicks) {
    auto r = invoke("mouse_click", QJsonObject{
        {"path", "MainWindow/okBtn"},
    });
    EXPECT_TRUE(r["clicked"].toBool());

    EXPECT_EQ(
        prop("MainWindow/statusLabel", "text"),
        "Logged in"
    );
}
using veriCue;

await using var client = new VeriCueClient();
await client.ConnectAsync("127.0.0.1", 4242);

await client.TypeTextAsync("LoginWindow/user", "alice");
await client.MouseClickAsync("LoginWindow/loginBtn");

var props = await client.GetPropertiesAsync(
    "MainWindow/statusLabel", new[] { "text" }
);
Assert.Equal("Logged in",
    props.GetProperty("text").GetString());

How it works

One open protocol, three boxes, zero magic.

Your Qt application embeds a small server. Your test code talks to it over TCP. That's it.

Step 1 - Test runtime

Your test code

Python (asyncio)
C++ (Qt signals/slots)
C# (.NET 8 TAP)
+ pytest / xUnit / Robot

Step 2 - Transport

Open TCP protocol

Length-prefixed JSON
Versioned handshake
Token auth (optional)
42 commands + push events

Step 3 - Embedded

veriCue server

One setLicenseFile()
One start(4242)
Walks QObject tree
QPA event delivery

Get in touch

Tell us about your stack.

We respond within one business day with a 30-day trial licence and a Quick Start tailored to your application. Pricing is public and transparent - from EUR 299 net/quarter, listed on the pricing page.

Trial licence Full functionality, 30 days, no payment details.
Trial onboarding Quick Start guide, max one 30-60 min onboarding session, integration confirmation, and a review of your first self-written test.
Implementation Sprint (paid) Want us to build your first tests? Up to 3 test scenarios plus 1 CI pipeline are part of the paid Implementation Sprint / Launch Bundle.
Sales call (optional) 30 minutes screen-share - we drive your app live to show you what fits.

Company

Your name

Work email

Role

Package of interest *

Qt version

UI stack

Operating system(s)

Test framework

CI platform

How many test sessions do you expect to run concurrently?

Expected implementation date

Short description of your Qt application

Typical response: within one business day.

Qt test automation,finally without the pain.