There are five realistic ways to automate testing of a Qt application. Each one is the right answer for somebody. This page lays them out side by side so you can pick the one that fits your team - including the cases where that is not veriCue.
| Criteria | QTest (in-process unit/GUI tests) |
Self-built in-house framework | Generic web/desktop automation tools | Squish / traditional enterprise GUI automation | veriCue |
|---|---|---|---|---|---|
| Qt Widgets support | Yes - in-process access to widgets and events | Whatever you build yourself | Indirect - image matching or OS accessibility APIs; Qt object internals are not visible | Yes - deep object-level support | Yes - object-level access over the protocol (paths, properties, events) |
| QML support | Qt Quick Test for component-level tests | Requires implementing QQuickItem traversal and input dispatch yourself | Screen-level only - the QML scene graph is invisible to external tools | Yes | Yes - auto-detected at build time, full visual tree traversal, scene-coordinate input |
| CI friendliness | Excellent - plain test binaries, runs offscreen | Depends entirely on how it was built | Often needs a real desktop session or virtual display | Good - plan for how CI runners are licensed and provisioned | Headless via QT_QPA_PLATFORM=offscreen in documented compatible environments (GL-dependent setups still need a display or Xvfb); local IPC on the runner, plain TCP across hosts and containers; pytest/CTest exit codes drive the pipeline |
| Recording | None | Rarely built - expensive to implement well | Usually yes, at screen/coordinate level | Yes - object-level recording | Yes - record and replay that generates editable Python scripts |
| Visual regression | Manual QImage comparison you write yourself | Build and maintain your own baseline handling | Core strength of image-based tools | Available | Built in - screenshot_compare against stored baselines |
| Test languages | C++ (QML for Qt Quick Test) | Whatever you choose - and then maintain | Tool-specific scripting or low-code editors | Vendor-supported scripting languages (Squish: JavaScript, Python, Perl, Tcl, Ruby) | Python, C++, .NET clients; pytest, Robot Framework, and GoogleTest adapters |
| Protocol openness | Not applicable - in-process, source available with Qt | Yours by definition | Typically proprietary | Proprietary | Open, documented 46-command JSON protocol, byte-identical over local IPC and TCP - you can write your own client |
| Deployment model | Compiled into dedicated test binaries | Custom - usually compiled into the app | External process driving OS-level input | Hook/injection toolchain plus vendor IDE and runner | The veriCue Runtime links into your application as a library, or is loaded into it at launch with no code changes - Linux x64 and Windows x64, dynamically linked Qt |
| Licensing model | Ships with Qt (open source or commercial Qt terms) | No license cost - you pay in engineering time | Varies - free/open source through per-user commercial | Commercial, typically per-seat or named-user, sales-led | Commercial, per concurrent automation session; offline license keys, no phone-home |
| Entry cost | None beyond Qt itself | High up-front engineering investment before the first stable test | Varies widely by tool | Quote via sales; procurement is part of the timeline | Free self-service 30-day trial, no sales contact; public pricing (see pricing) |
| Vendor lock-in | None - it is part of Qt | Locked to your own code and the people who wrote it | Tests coupled to screen layout and the tool's format | Tests written against a proprietary API and IDE | Tests are standard pytest/Robot/GoogleTest code against a documented protocol |
| Time to first test | Minutes for unit tests; GUI tests grow with app complexity | Weeks to months of framework work first | Fast for simple flows; upkeep grows as the UI changes | Typically days, including toolchain setup | Under an hour in most apps: start the veriCue Runtime in your app (or inject it on a compatible Linux x64 target), connect with the Python client |
So the row above is verifiable: veriCue is a Runtime that runs inside your Qt application - linked in as a library, or loaded into a compatible target at launch without build changes. External clients talk to it over an open, documented JSON protocol - a local IPC endpoint when they run on the same machine, TCP when they have to cross a host, container or device boundary - and drive the real application: real widgets, real QML items, real input events.
screenshot_compare with stored baselinesstartLocal(), a user-private UNIX socket) for same-host runs on Linux and macOS; TCP (start()) for cross-host, container and device runs - and as the supported local transport on Windows, where local IPC is not availablevericue run and have the Runtime loaded into it without touching application code. Both are supported. The zero-source-change path covers Linux x64 and Windows x64 and requires the target to link Qt dynamically with a matching Qt major version. The mechanism differs per platform: on Linux the Runtime is preloaded into the process (LD_PRELOAD) and the default transport is a user-private local socket; on Windows it is a launch-time DLL load that endpoint security can block, and the transport is TCP. macOS is not in that path - its hardened runtime refuses to load code into another process - so embedding stays the answer there. Either way veriCue code runs inside the process under testAn honest tool page should say this part out loud:
Many teams also combine approaches: QTest for units, veriCue for end-to-end GUI flows in CI. They are complementary, not competing.
Describe your application and constraints - we will tell you honestly if veriCue is a fit, and what we would use if not.
Or read the documentation and judge for yourself.