Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Introduction

Victauri — Verified Introspection & Control for Tauri Applications.

Victauri is full-stack testing for Tauri apps. Click a button in the frontend, verify the Rust command ran, confirm the database row was written — from a single test, on macOS, Windows, and Linux, in CI. Unlike browser automation tools like Playwright — which can’t even attach to a Tauri webview on macOS or Linux — Victauri runs inside the app process with simultaneous access to the webview DOM, the IPC layer, the Rust backend, the database, and native window state (the database and backend introspection tools — query_db, app_state, app_info, memory/process stats — are read-only; invoke_command can deliberately call mutating commands, exactly like the frontend).

It works by embedding a lightweight server inside your Tauri app’s own process — debug builds only; the server is gated behind #[cfg(debug_assertions)], so init() is a no-op and nothing listens in release. Your test suite, curl, or CI talks to it over a plain REST/HTTP API. No WebDriver, no Selenium grid, no browser dependency.

And because that same server also speaks the Model Context Protocol (MCP), any AI agent — Claude Code, Cursor, Windsurf — gets the exact same full-stack access for interactive debugging. Testing is the job; the agent integration is the bonus.

Who Is This For?

  • Tauri app developers who want real full-stack tests (frontend → IPC → Rust → database) instead of frontend mocks that lie about the backend
  • QA and CI engineers who need cross-platform end-to-end tests without standing up a WebDriver/Selenium grid or paying for macOS runners
  • AI agent developers who need to drive, debug, or inspect a running Tauri application over MCP

Key Value Proposition

One plugin, one line of code, full-stack access:

LayerWhat You Get
WebViewDOM snapshots, element interaction, JS evaluation, CSS inspection
IPCCommand registry, invoke commands, intercept and log IPC traffic
BackendState reading, memory tracking, process diagnostics
WindowsMulti-window management, screenshots, positioning
Time-TravelRecord sessions, checkpoint state, replay events

All of this is exposed two ways from the same server: a plain REST/HTTP API (POST /api/tools/{name}) that your test suite, shell scripts, and CI call directly — no handshake, no session — and the Model Context Protocol (MCP) for AI agents. Write deterministic tests against REST; connect Claude Code, Cursor, or any MCP client when you want an agent to drive the app interactively.

Design Principles

  1. Same-process — The MCP server runs inside the Tauri app process, not as a separate sidecar. This gives direct AppHandle access with no extra process hop: Rust-side tools (registry, memory, app_state, query_db, window state) answer in well under a millisecond; webview tools (eval_js, dom_snapshot, interact, …) are a JS round trip through the webview, typically ~10-30 ms.

  2. Zero runtime cost in release — The server is gated behind #[cfg(debug_assertions)], so init() is a no-op and nothing listens in release builds. Add it as a normal [dependencies] entry — the app binary cannot use [dev-dependencies]. The crate still compiles in; to keep it out of release binaries entirely, make it an optional dependency behind a Cargo feature and gate the .plugin(...) call on that feature.

  3. Full-stack — WebView + IPC + Backend + DB, not just DOM. Cross-boundary verification catches state drift between frontend and backend.

  4. MCP-native — Speaks the protocol AI agents already understand. No custom SDKs or adapters needed.

  5. Cross-platform — The same tool surface on Windows, macOS, and Linux, with no CDP dependency. Documented platform limits: trusted (OS-level, isTrusted: true) input is Windows-only (other platforms fall back to synthetic events), and window screenshots on Linux need X11/XWayland (pure Wayland returns a clear error).

  6. Plugin, not framework — One line in Cargo.toml to add, one line to remove. Your app architecture stays unchanged.

Project Structure

Victauri is a Rust workspace with 6 crates:

victauri/
├── crates/
│   ├── victauri-cli/        # CLI: init, check, test, record, watch, coverage
│   ├── victauri-core/       # Shared types: events, registry, snapshots
│   ├── victauri-macros/     # Proc macros: #[inspectable]
│   ├── victauri-plugin/     # Tauri plugin: embedded MCP server + JS bridge
│   ├── victauri-test/       # Test client + assertion helpers
│   └── victauri-watchdog/   # Crash-recovery health monitor
├── editors/
│   └── vscode/              # VS Code extension
└── examples/
    └── demo-app/            # Reference Tauri app with full test suite

Current Status

All 6 crates are published to crates.io. In a one-time deep evaluation (May 2026) against 5 real-world open-source Tauri apps (Kanri, En Croissant, Surrealist, Duckling, Lettura), 867 of 895 checks passed (96.9%) with zero Victauri bugs and zero changes required to the apps — the remaining failures were test-script issues or correct actionability enforcement. A reproducible per-release compatibility harness (scripts/compat) now re-verifies against these apps automatically; three of those apps (Kanri, En Croissant, Lettura) are pinned in it and pass its 15-check battery; the other two are not in the harness (see scripts/compat/README.md for why). Supports Tauri 2.0+ with rmcp 3.1 (MCP protocol 2026-07-28, backward compatible down to 2024-11-05).

Victauri is open source (Apache-2.0) and built by 4DA Systems, which uses it to test its own Tauri app. Adopters and contributors are very welcome — see Contributing, and if you ship a Tauri app we’d love to hear how it goes.