| 📦 Turbo JS 91999d1 k33g 12h ago | 1 | # Lancer les tests |
| 2 | |
| 3 | Ce guide montre comment exécuter et lire la suite de tests de Turbo JS. Il suppose que vous avez un clone du dépôt et Go 1.26 ou plus récent. |
| 4 | |
| 5 | ## Toute la suite |
| 6 | |
| 7 | ```bash |
| 8 | make test |
| 9 | ``` |
| 10 | |
| 11 | C'est la commande unique documentée. Elle exécute `go test ./...` sur tous les paquets. |
| 12 | |
| 13 | ## Variantes |
| 14 | |
| 15 | **Voir chaque test par son nom :** |
| 16 | |
| 17 | ```bash |
| 18 | make test-verbose |
| 19 | ``` |
| 20 | |
| 21 | **Mesurer la couverture par paquet :** |
| 22 | |
| 23 | ```bash |
| 24 | make cover |
| 25 | ``` |
| 26 | |
| 27 | **Un seul paquet :** |
| 28 | |
| 29 | ```bash |
| 30 | go test ./internal/jslang/ |
| 31 | ``` |
| 32 | |
| 33 | **Sans lancer de serveur de langage, et sans compiler l'éditeur entier.** Les tests de `internal/jslang` qui portent `WithRealServer` dans leur nom démarrent un vrai `typescript-language-server` s'ils en trouvent un, et les tests de l'installeur compilent tout l'éditeur. Pour les sauter : |
| 34 | |
| 35 | ```bash |
| 36 | go test -short ./... |
| 37 | ``` |
| 38 | |
| 39 | **Tout ce qu'un commit devrait passer :** |
| 40 | |
| 41 | ```bash |
| 42 | make check |
| 43 | ``` |
| 44 | |
| 45 | Cela enchaîne `go fmt`, `go vet` et les tests, dans cet ordre. |
| 46 | |
| 47 | ## Ce que la suite couvre |
| 48 | |
| 49 | Aucun test n'a besoin d'un vrai terminal : l'éditeur est dessiné sur le `SimulationScreen` de tcell — un vrai `Screen` qui dessine en mémoire — si bien que les assertions portent sur l'image qu'un terminal afficherait réellement. |
| 50 | |
| 51 | Ce que ce dépôt teste est ce qui n'appartient qu'à lui : |
| 52 | |
| 53 | - **Le scanner.** Chaque construction que le scanner colore, et chaque chose qu'il refuse de colorer — un `/` après une valeur divise au lieu d'ouvrir une expression régulière, `#!` n'est un commentaire qu'en première ligne — ; un *template literal* ou un commentaire `/* */` portés jusqu'à leur fermeture, sur autant de lignes qu'il faut, et une chaîne `'…'` arrêtée à la fin de sa ligne ; et les globales de Node — `process`, `Buffer`, `require` — tenues pour des fonctions intégrées. |
| 54 | - **Le profil.** Le nom de l'éditeur, le menu **JavaScript** et sa touche `Alt-J` qui n'entre en conflit avec aucun menu fixe, `package.json` comme marqueur de racine — le plus proche l'emporte dans un monorepo —, le serveur qui est `typescript-language-server --stdio`, et les dossiers où il est cherché après le `PATH` : ceux des gestionnaires de versions de Node, puis `/usr/local/bin` et `/opt/homebrew/bin`. |
| 55 | - **Les fichiers de départ.** Chaque snippet se charge et vise `javascript` ou `json`, les corps sont indentés de deux espaces, comme Prettier ; chaque outil se charge et lance `node`, `npm` ou `npx`, et seul **Run** demande une valeur ; deux outils d'un même menu ne se disputent jamais une lettre. |
| 56 | - **Le serveur, pour de vrai.** Complétion, déclaration, description d'une fonction avec le commentaire JSDoc au-dessus d'elle, définition du type d'une instance, implémentations d'une classe, références, plan du fichier, symbole dans le projet, et diagnostic d'un fichier qui ne s'analyse pas — les neuf questions que l'éditeur sait poser, toutes traitées par `typescript-language-server`. Ces tests **se sautent eux-mêmes** quand `typescript-language-server` n'est pas installé : un clone sans Node.js a donc quand même une suite verte. |
| 57 | - **L'installeur et la version.** Un test compile l'éditeur par `scripts/install.sh` dans un préfixe temporaire et vérifie qu'il annonce `Turbo JS` et le commit ; d'autres tiennent `scripts/check-version.sh` et les scripts de release à ce qu'ils promettent. |
| 58 | |
| 59 | Tout le reste — le buffer, les fenêtres, le client LSP, les terminaux, l'arbre, les snippets, les thèmes — est testé dans turbo-core. |
| 60 | |
| 61 | ## Tester sur un turbo-core non publié |
| 62 | |
| 63 | L'essentiel de Turbo JS est turbo-core, et ce dépôt en dépend par version, depuis le proxy de modules : |
| 64 | |
| 65 | ``` |
| 66 | require rickub.com/turbo-editors/turbo-core v0.8.0 |
| 67 | ``` |
| 68 | |
| 69 | Une modification faite dans une copie de turbo-core placée à côté de celle-ci est donc invisible ici tant qu'elle n'est pas publiée. Pour la tester avant, créez un espace de travail : |
| 70 | |
| 71 | ```bash |
| 72 | go work init . ../turbo-core |
| 73 | make test |
| 74 | ``` |
| 75 | |
| 76 | Chaque import de la bibliothèque pointe désormais sur cette copie. Ni `go.mod` ni `go.sum` ne changent : il n'y a donc rien à défaire. Vérifiez que c'est bien pris en compte — c'est l'erreur contre laquelle il faut se prémunir, car sinon tout compile et tout passe quand même : |
| 77 | |
| 78 | ```bash |
| 79 | go list -f '{{.Dir}}' rickub.com/turbo-editors/turbo-core/app |
| 80 | ``` |
| 81 | |
| 82 | La réponse doit être votre copie de travail, pas un chemin sous `pkg/mod`. Une fois terminé, `rm go.work go.work.sum` ; le fichier est ignoré par git, il ne peut donc pas être commité par accident. |
| 83 | |
| 84 | ## Qualité du code |
| 85 | |
| 86 | La suite de tests n'est pas toute la porte de qualité. Celle-ci se mesure à part : |
| 87 | |
| 88 | ```bash |
| 89 | python3 ~/.claude/skills/quality/scripts/quality_report.py --workspace . |
| 90 | ``` |
| 91 | |
| 92 | Elle écrit un rapport sous `.quality/` et sort en erreur si la porte échoue. |
| 93 | |
| 94 | ## Voir aussi |
| 95 | |
| 96 | - Pourquoi les tests ont cette forme : [Architecture](../explanation/architecture.md) |
| 97 | - Toutes les cibles make : [référence de la ligne de commande](../reference/cli.md) |