Synthèse automatique
Guide la rédaction et la maintenance des tests end-to-end de Termic, qui pilotent la vraie fenêtre macOS via WebdriverIO pour couvrir chaque nouveau flux d'interface.
Points forts
- Workflow explicite : nouveau composant → nouveau spec, composant modifié → spec mis à jour, `make e2e` vert avant de conclure
- Montre comment lire l'état réel de l'application via `window.__termic` plutôt que de scraper le DOM
- Règles de stabilité claires : aucune temporisation fixe, uniquement des attentes conditionnelles
- Signale le piège classique du binaire e2e construit avec `cargo build` qui ouvre une fenêtre blanche
Limites
- Spécifique à Termic (helpers, binaire e2e, `window.__termic`) et non transposable tel quel à un autre projet
- Tests exécutés uniquement en local sur Mac, sans job CI par conception
- Le document fourni s'interrompt au milieu des règles de stabilité, la fin des consignes n'est pas couverte
À utiliser dès qu'on ajoute ou modifie une fonctionnalité de Termic ayant une interface ou un flux utilisateur, avant de la déclarer terminée.
À ne pas utiliser pour des tests unitaires, des tests d'intégration Rust ou tout projet qui n'est pas l'application Termic.
Analyse de sécurité
SûrThe skill is a development/test authoring guide. Its commands are local build and WebdriverIO test runs against an isolated `.e2e/profile` directory; it explicitly avoids CI, uses fake agents with zero tokens, and its example IPC calls are bound to a test-only handle stripped from release builds. There are no curl|sh pipes, no rm -rf, no secret/token exfiltration, no base64 payloads, and no safety-disabling instructions. Execution risk is limited to standard repo tooling.
- •Requires running repo-local build/test tooling (`make e2e`, `npm run e2e:build`, `npm run test:e2e`) which executes whatever those scripts contain — trust in the repo is assumed, but nothing in the skill is destructive.
- •Uses `browser.execute` and a test-only `window.__termic` handle to read stores and call IPC directly; scoped to the e2e build (VITE_E2E=1) and an isolated throwaway profile, not a real exfiltration path.
Exemples
I just added a workspace archive action to Termic. Write an e2e spec for it in e2e/specs/ using the shared helpers, then run make e2e and confirm it's green.The History empty state text changed from 'No archived tasks.' to 'History is empty.'. Update the archive spec's assertions and re-run the suite.I refactored the workspace sidebar UI. Run the e2e suite and make sure no existing spec regressed before I mark this done.name: e2e description: Write and maintain termic's automated end-to-end tests (WebdriverIO driving the real macOS window). Use whenever you develop a NEW feature (add a spec that exercises its flow), CHANGE an existing feature (update its spec), or need to verify a UI flow before declaring done. This is how termic avoids UI regressions. Replaces the old automation-bridge driving skill.
Authoring & maintaining termic e2e tests
Automated, repeatable tests that launch the real Termic window, click through real flows, read real app state, and screenshot. The point is regression safety: every new feature with a UI/flow surface gets a spec, and every change to an existing feature updates its spec. Don't skip it.
Full architecture + prod-safety rationale: docs/e2e-tests.md.
The workflow (do this every time)
New feature → add e2e/specs/<feature>.e2e.ts covering its main
user-observable outcome(s). Changed feature → open that feature's spec,
adjust the assertion/selectors to the new behavior (keep asserting the
outcome, not incidental markup), and re-run. Before declaring done on any
UI-affecting change → make e2e must be green.
Run
make e2e # build the --features e2e binary + run the whole suite
Iterating on spec files only? Skip the rebuild:
npm run test:e2e # just runs wdio against the last-built binary
Rebuild (npm run e2e:build, or make e2e) after any Rust or frontend
change — the frontend is embedded in the e2e binary. Screenshots land in
.e2e/artifacts/ (gitignored). Local Mac only; there is no CI job by design
(the tests launch a GUI window).
Never build the e2e binary with a bare cargo build — that produces a binary
that points at the (unrunning) dev server and the window comes up blank. Always
go through npm run e2e:build / make e2e (it runs tauri build, which
embeds the frontend). If a run shows url: about:blank / a white window, this
is the cause.
Writing a spec
Use the shared helpers in e2e/helpers.ts so specs stay short and a UI change is a one-place fix. Reference example: e2e/specs/smoke.e2e.ts.
import { waitForAppShell, clickByText, waitForText } from "../helpers.js";
describe("archive a task", () => {
it("moves the task to History", async () => {
await waitForAppShell();
await clickByText("Archive");
await waitForText("No archived tasks."); // auto-retries; no sleep
});
});
One it = one user-observable outcome. All its in a file share ONE launched
window (boot once, assert many) — order them so earlier tests don't leave state
that breaks later ones, or reset between them.
Reading real app state (prefer this over DOM scraping)
The e2e binary exposes window.__termic (stores + ipc + invoke — same handle
the dev bridge uses; enabled via VITE_E2E=1, stripped from real release
builds). Read state or drive real IPC through browser.execute:
// Read store state
const names = await browser.execute(() =>
window.__termic!.useApp.getState().workspaces.map((w: any) => w.name));
// Set up state fast by driving the app's own IPC (no clicking through wizards)
const wsId = await browser.execute(async () => {
const t = window.__termic!;
const proj = t.useApp.getState().projects.find((p: any) => p.name === "fixture-repo");
const ws = await t.invoke("workspace_open_repo",
{ projectId: proj.id, cli: "fakeagent", name: null });
await t.useApp.getState().loadAll();
t.useApp.getState().setActiveWorkspace(ws.id);
return ws.id;
});
requireTermicApi() asserts the handle is present (fails loudly if you ran an
old/non-e2e binary).
Stability rules (non-negotiable — this is what keeps the suite non-fuzzy)
- Never sleep. No
setTimeout/ fixed waits. Usebrowser.waitUntil, thewaitFor*helpers, or auto-retryingexpect. Every wait is a condition. - Assert on state / DOM text, not pixels. Screenshots are for humans to eyeball, never for assertions.
- Terminal content is NOT in the DOM. xterm renders to a WebGL canvas, so
innerTextnever contains PTY output no matter how long you wait. Assert terminal activity via store state — e.g.tab.lastOutputAt(bytes flowed) ortab.liveTitle(the agent's OSC title) read throughwindow.__termic. All OTHER UI (sidebar, tabs, dialogs, Git panel) is normal DOM.scripts/fake-agent.shmimics claude: it drives the OSC title with claude's glyphs (✳idle / Braille spinner working). NOTE:tab.workState === "working"won't flip from a rawipc.ptyWrite— termic gates the working indicator on a real submit through its input path, so assertliveTitlefor OSC-title checks, notworkState. Seee2e/specs/task-spawn.e2e.ts. - Semantic selectors. Match by role / visible text (
clickByText). Add adata-testidonly where text is ambiguous or localized. Never depend on generated class names. - Deterministic fixtures. Runs use the isolated
.e2e/profile(welcomed+ thefixture-repoproject + the zero-tokenfakeagent). Agent flows usefakeagent(scripts/fake-agent.sh, real PTY, zero tokens). Don't depend on state a previous test left behind.
Fixtures / isolation
wdio.conf.ts launches the app against TERMIC_DATA_DIR=.e2e/profile, a
throwaway profile seeded once (the same one the ad-hoc bridge used), so a run
never touches your real termic_dev data. Paths round-trip canonicalized on
projectAdd (symlinks resolved), so match projects by name, not by the path
you passed in.
Debugging a failing spec
- See what's actually on screen: the spec should
saveScreenshotinto.e2e/artifacts/; open it. A blank white window ⇒ the about:blank build issue above. - Wrong webview / empty DOM: enumerate handles —
await browser.getWindowHandles()thenswitchToWindow(h)and loglocation.hrefper handle. The app content is themainhandle at atauri://URL, notabout:blank. - Occluded window: if the window is on another Space / behind others,
document.visibilityStateishiddenand rAF is frozen.browser.execute, IPC, and store reads still work; only rAF-driven visual updates stall. window.__termicundefined: you're running a non-e2e binary —make e2e.
Ad-hoc / exploratory driving (not a written test)
For one-off manual poking where you don't (yet) want a spec, the dev automation
bridge still exists (src-tauri/src/automation.rs, TERMIC_AUTOMATION=1 under
tauri dev) — see docs/automation.md. But
anything meant to prevent a regression belongs in a spec here, not a throwaway
eval.
Maturity caveat
@wdio/tauri-service + tauri-plugin-wdio-webdriver are young (1.x, 2026) and
maintained by the WebdriverIO org. package.json pins @wdio/native-utils to
2.5.0 via overrides to work around a broken pin in tauri-service 1.2.0. If a
future upgrade breaks, pin the @wdio/* packages and tauri-plugin-wdio-webdriver
in lockstep to the last-known-good set.
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/automated-e2e-tests-mryiqijz/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/automated-e2e-tests-mryiqijz' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/automated-e2e-tests-mryiqijz/download' --output '.skill-downloads/automated-e2e-tests-mryiqijz/SKILL.md.part' && mv '.skill-downloads/automated-e2e-tests-mryiqijz/SKILL.md.part' '.skill-downloads/automated-e2e-tests-mryiqijz/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.
Claude Code
test -f '.skill-downloads/automated-e2e-tests-mryiqijz/SKILL.md' && test -s '.skill-downloads/automated-e2e-tests-mryiqijz/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/e2e' && cp -R '.skill-downloads/automated-e2e-tests-mryiqijz' '.claude/skills/e2e'OpenSkills
OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.
Installation officielle d’OpenSkillsopenskills install './.skill-downloads/automated-e2e-tests-mryiqijz'openskills read 'automated-e2e-tests-mryiqijz'La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.
Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.
openskills syncMode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/automated-e2e-tests-mryiqijz/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Comparaison de performances ClickHouse
Testing
Évaluez les résultats de tests de performance ClickHouse, analysez les régressions de PR, comparez avec l'historique et vérifiez la fiabilité des mesures.
Analyse des rapports de performance CI
Testing
Analyse les rapports de comparaison de performance CI pour une PR ClickHouse. Recoupe l'historique master pour distinguer les vraies régressions des tests instables.
Méthode Santa
Testing
Vérification adversarial multi-agents avec deux réviseurs indépendants. La sortie est vérifiée deux fois et corrigée itérativement jusqu'à ce que les deux acceptent avant publication.