已發布·持續改進
Tauri 指南 · 5/6
本章目前僅提供英文版。
A Tauri app is a Rust core and a web frontend working together, so it pays to test in layers. This chapter covers Rust unit tests, frontend tests with a mocked IPC layer, and WebDriver-based end-to-end tests that drive the real app window.
| Layer | Tools | What it checks |
|---|---|---|
| Rust unit tests | cargo test | Commands and business logic |
| Frontend tests | Vitest + @tauri-apps/api/mocks | UI logic and invoke calls |
| End-to-end tests | WebdriverIO or Selenium + WebDriver | The whole built app |
A function marked #[tauri::command] is still a plain Rust function, so tests can call it directly. Even better, keep logic in pure functions and make commands a thin layer that calls them; that makes testing much easier.
// src-tauri/src/lib.rs
fn normalize_title(title: &str) -> String {
title.trim().to_string()
}
#[tauri::command]
fn divide(a: f64, b: f64) -> Result<f64, String> {
if b == 0.0 {
return Err("cannot divide by zero".into());
}
Ok(a / b)
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn trims_title() {
assert_eq!(normalize_title(" groceries "), "groceries");
}
#[test]
fn divide_by_zero_is_error() {
assert!(divide(1.0, 0.0).is_err());
assert_eq!(divide(9.0, 3.0), Ok(3.0));
}
}Run the tests from src-tauri, or pass the manifest path from the repository root.
cd src-tauri && cargo test
# or, from the repository root
cargo test --manifest-path src-tauri/Cargo.tomlTo exercise commands that take State or AppHandle through the real IPC path, enable the test feature of the tauri crate and use the mock runtime in tauri::test (mock_builder, mock_context, noop_assets) to build an app without opening a window.
A plain browser or jsdom has no Tauri core behind it, so invoke cannot work as is. mockIPC from @tauri-apps/api/mocks fakes command responses, letting you test UI code with Vitest or Jest. Set environment to "jsdom" in your Vitest config.
// src/greet.test.ts
import { afterEach, beforeAll, expect, test } from "vitest";
import { randomFillSync } from "node:crypto";
import { clearMocks, mockIPC } from "@tauri-apps/api/mocks";
import { invoke } from "@tauri-apps/api/core";
beforeAll(() => {
// jsdom has no WebCrypto implementation, so provide one
Object.defineProperty(window, "crypto", {
value: { getRandomValues: (buffer: any) => randomFillSync(buffer) },
});
});
// Reset mocked state between tests
afterEach(() => clearMocks());
test("mocks the greet command", async () => {
mockIPC((cmd, args) => {
if (cmd === "greet") return `Hello, ${(args as { name: string }).name}!`;
});
await expect(invoke("greet", { name: "Tauri" })).resolves.toBe("Hello, Tauri!");
});mockWindows from the same module fakes window labels. To assert which arguments the UI sends, record the args received inside mockIPC and check them afterwards.
To launch the built app, click buttons and verify results, use WebDriver, the W3C automation standard. The approach recommended by the official docs is the WebdriverIO Tauri service (@wdio/tauri-service); running npm create wdio@latest ./ and choosing Desktop Testing, then Tauri, generates the setup. The default embedded provider relies on the tauri-plugin-wdio-webdriver plugin, which runs a WebDriver server inside your app, and works on Windows, Linux and macOS. It is wise to include that plugin only in test builds.
// wdio.conf.ts
export const config: WebdriverIO.Config = {
specs: ["./e2e/**/*.e2e.ts"],
framework: "mocha",
services: [
["tauri", {
appBinaryPath: "./src-tauri/target/release/tauri-app",
driverProvider: "embedded",
}],
],
};// e2e/greet.e2e.ts
describe("greeting screen", () => {
it("shows a greeting after entering a name", async () => {
await $("#greet-input").setValue("Tauri");
await $("button[type='submit']").click();
await expect($("#greet-msg")).toHaveText(/Tauri/);
});
});The traditional route is tauri-driver, installed with cargo install tauri-driver --locked, which wraps the platform's native WebDriver. On Windows it needs an msedgedriver.exe matching the installed Edge version on your PATH (a mismatch can make the suite hang while connecting); on Linux it needs WebKitWebDriver, packaged as webkit2gtk-driver on Debian-based systems. macOS has no WebDriver tool for WKWebView, so this route does not work there. If you do not use Node.js, pair it with another WebDriver client such as Selenium.
Linux CI runners have no display, so run end-to-end tests under a virtual display such as xvfb-run.
cargo test and keep commands thin.mockIPC in Vitest or similar, and call clearMocks between tests.tauri-driver supports only Windows and Linux.
0 則留言
登入 · 登入後即可留言。
來留下第一則留言吧。