Tests

Deux suites complémentaires :

	Vitest (npm test)	Playwright (npm run test:e2e)
Vérifie	la logique de CapyCode : stores, services, composants	le comportement réel, dans Chromium, avec les vrais noyaux Basthon
Environnement	Node, fake-indexeddb, jsdom pour les composants	serveur de dev (port 5174), réseau vers cdn.basthon.fr
Exécution du code	faux noyau (tests/helpers/fake-kernel.ts)	vrai Pyodide, vrais paquets
Durée	quelques secondes en tout	une dizaine de secondes par test
En CI	job test, avec le lint	job e2e, après test

Rangement : par domaine

Les tests sont rangés par domaine (« centre d'intérêt »), pas par couche : tests/workspace/, project/, git/, terminal/, execution/, editor/, search/, python-analysis/, interface/, accessibility/, et e2e/ pour Playwright. Un test de store, de service ou de composant va dans le dossier de ce qu'il vérifie.

• Chaque fichier commence par un commentaire en français : une ligne de vue d'ensemble, puis le but de chaque groupe de tests, dans l'ordre du fichier.
• Chaque dossier a un README.md : le domaine, et une ou deux lignes par fichier. tests/README.md donne la carte d'ensemble.
• Un test qui a besoin de fichiers charge le ZIP du même nom que son fichier (modules-packages.e2e.ts → modules-packages.zip) : un seul projet par fichier de test.

Ces règles viennent du cahier des charges testing.md (à la racine) ; la skill tests-organisation les reprend pour les agents.

Vitest

• tests/setup.ts (chargé avant chaque fichier) : fake-indexeddb pour LightningFS, Ruff WASM lu depuis le disque, langue remise en anglais et stores libérés après chaque test. Chaque test crée son propre Pinia, mais vfs et gitService sont des singletons : sans libération, les stores des tests précédents resteraient abonnés et chaque écriture les réveillerait tous.
• Composants : // @vitest-environment jsdom en tête du fichier, @vue/test-utils. Un composant qui utilise des commandes se monte avec withCommands(Composant) (tests/helpers/commands.ts).
• Terminal : createShell() (tests/helpers/terminal.ts) donne un terminal sans interface (répertoire courant, historique, Python factice) ; useTestTerminal() une session du store.
• CodeMirror : parsedState() (tests/helpers/editor.ts) crée un état dont l'arbre syntaxique est complet. EditorState.create n'analyse le document que pendant un court budget de temps, et l'arbre peut rester incomplet sur une machine chargée.
• Pour un test pédagogique en français, await setLocale('fr') (remis en anglais après le test).

Le faux noyau

Les noyaux Basthon ne tournent pas sous Node (il leur faut un worker de navigateur et Pyodide). FakeKernel reproduit le contrat que CapyCode utilise : événements sur le document (eval.output, eval.display, eval.input), evalAsync, more, complete, putFile. Un test lui dit comment répondre à chaque évaluation.

Il reste utile à côté des tests de bout en bout : il vérifie en quelques millisecondes quelle console reçoit quelle sortie, les statuts, l'interruption, le redémarrage, et il provoque des cas difficiles à obtenir du vrai noyau (arrêt en plein calcul, sorties de deux sessions entremêlées, saisie annulée). Il ne doit pas servir à tester Python lui-même : c'est le rôle de Playwright. Tout ce qui touche à l'intégration Basthon est aussi couvert en bout en bout, pour que le faux noyau ne s'écarte pas du vrai sans qu'on le voie.

Playwright (tests/e2e/)

• Les tests importent test et expect de tests/e2e/helpers/fixtures.ts, qui fournit app, un pilote de l'application (helpers/capycode.ts : terminal, console, bouton Exécuter, import d'un projet).
• Chaque test part du projet de départ, stockage vidé… sauf l'instantané mémoire de Pyodide (IndexedDB basthon-python3) : chaque worker Playwright garde son profil de navigateur (node_modules/.cache/capycode-e2e/, dossier temporaire en CI), et Pyodide y redémarre depuis l'instantané. Un test simple passe ainsi d'environ 20 s à 8 s.
• Délais : 90 s pour qu'un noyau démarre, 2 min par test (5 min en CI, où le runner est lent). En CI, un test échoué est rejoué une fois : le CDN de Basthon refuse parfois un chargement.
• test.fixme marque un comportement attendu mais empêché par un défaut connu de Basthon (voir Pistes).

npx playwright install chromium   # une fois
npm run test:e2e                  # tout
npx playwright test tests/e2e/history

Accessibilité

tests/accessibility/accessibility-axe.spec.ts audite chaque composant avec axe-core (0 violation) et vérifie les contrastes des jetons de couleur des deux thèmes ; keyboard-navigation.spec.ts vérifie les comportements au clavier. Tout nouveau composant y est ajouté. jsdom ne calcule pas le rendu : un audit axe dans le navigateur, dans les deux thèmes, complète ces tests (voir Accessibilité).

Ce qu'aucun test ne couvre

• Le rendu réel des sorties graphiques (turtle, matplotlib, tkinter) : à regarder dans le navigateur.
• Le service worker et les mises à jour : scénario manuel décrit dans Déploiement.
• SQL et OCaml n'ont pas de test de bout en bout : à vérifier à la main après une mise à jour de Basthon.