Mock Testing
Verify your state-machine logic without a live GUI — fast, deterministic, and CI-friendly
What is Mock Testing?
Mock mode runs your automation against simulated state and match results instead of capturing the real screen. The action layer is completely unchanged — actions like Find, Click, and Type execute exactly as they would in production, but the matches they receive come from recorded history rather than live image recognition.
Key Concept: Same Code Path, Simulated Inputs
Qontinui (descended from Brobot) uses the same Match objects for both mock and real automation — there is no separate "test type." The mock find implementation returns results in the identical format as the real one, so the logic you verify in mock mode is the same logic that runs against the real GUI.
This lets you exercise the structure of your automation — which states are reached, which transitions fire, in what order — without needing the target application open, a particular screen resolution, or even a display at all.
Why Mock Testing Matters
Fast
No screen capture, no template matching, no real waits. Mock time elapses instantly, so a workflow that takes minutes against a live GUI completes in milliseconds.
Deterministic
Recorded match results are replayed identically every run. The same inputs always produce the same path through your state machine — no flaky pixels.
CI-Friendly
Because no display is required, mock runs work in headless CI environments. Catch broken transitions and unreachable states before deploying to a real machine.
Logic-Focused
Separate state-machine correctness from image-recognition tuning. Verify your flow first, then refine similarity thresholds against the real screen.
How Mock Mode Works
When mock mode is enabled, Qontinui swaps its execution backend. Each of the three execution modes routes actions differently:
Real
Full automation through the hardware abstraction layer — live screen capture plus OpenCV template matching. This is the default for production runs.
Mock
Historical-data playback. Find requests are answered from recorded matches instead of the screen, and timed waits resolve instantly.
Screenshot
Matching runs against captured screenshots rather than the live display — useful for reproducing a recorded scene deterministically.
Where Mock Matches Come From
In mock mode, a find action resolves matches in priority order:
- 1Recorded Action History
Pre-recorded results attached to a pattern (fastest path — no external lookup)
- 2Historical Data
Previously captured results from the local database, if available
- 3Probabilistic Fallback
A generated mock match based on state probability when no recorded data exists
Action Snapshots
The raw material for mock playback is the action snapshot — a historical record of a single action execution. Each record captures everything needed to replay the action deterministically:
Action Type & Result
What was performed (FIND, CLICK, TYPE…) and whether it succeeded
Match List
The actual Match objects found — the same type used for real matches
Active States
Which states were active when the action ran, so playback respects context
Duration & Timestamp
Timing metadata used to model elapsed time without real waiting
Note: Snapshots store real Match objects — there is no separate snapshot type. This mirrors Brobot's design and is why mock and real runs share one code path.
Enabling Mock Mode
Mock mode is a single global switch with a few equivalent ways to set it:
Configuration Setting
Set the execution mode to mock in your exported configuration's execution settings.
"execution": { "executionMode": "mock" }Environment Variable
Set the mock-mode environment variable before running — accepts true / 1 / yes / on.
QONTINUI_MOCK_MODE=trueTest Environment (Automatic)
Mock mode turns on automatically when running under a test runner, so unit tests never touch the real screen.
(auto-enabled under pytest)Browser Mock Execution: Qontinui Web can run your automation logic directly in the browser without a real GUI environment — ideal for rapid iteration while you build a workflow in the visual editor.
Recommended Workflow
Build Your State Machine
Define states, identifying images, and transitions in the visual builder.
Run in Mock Mode
Execute the automation with mock mode enabled to confirm the intended states are reached and transitions fire in the right order.
Fix Logic Issues
Resolve unreachable states, missing transitions, or wrong action ordering — all without touching the real application.
Switch to Real Mode
Once the logic is sound, run against the live GUI and tune similarity thresholds for reliable image recognition.