| 📦 Turbo Golo d710c1b k33g 17h ago | 1 | # Lancer les tests |
| 2 | |
| 3 | Ce guide montre comment exécuter et lire la suite de tests de Turbo Golo. 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/gololang/ |
| 31 | ``` |
| 32 | |
| 33 | **Sans lancer de serveur de langage, et sans compiler l'éditeur entier.** Les tests de `internal/gololang` qui portent `WithRealGoloLSP` dans leur nom démarrent un vrai `golo lsp` 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 — `0xFF` n'est pas un nombre, `1_000` non plus — ; une chaîne ou un commentaire `----` portés jusqu'à leur fermeture, sur autant de lignes qu'il faut ; et deux tests qui tiennent la table des mots-clés et celle des fonctions intégrées à ce que le vrai `golo lsp` propose. |
| 54 | - **Le profil.** Le nom de l'éditeur, le menu **Golo** et sa touche `Alt-G` qui n'entre en conflit avec aucun menu fixe, l'absence de marqueur de projet, le serveur qui est l'interpréteur en mode `lsp`, et le dossier `/usr/local/bin` où il est cherché après le `PATH`. |
| 55 | - **Les fichiers de départ.** Chaque snippet se charge et vise `golo`, les corps sont indentés de deux espaces et écrits en chaînes littérales TOML ; chaque outil se charge et lance `golo`, `gogolo` ou `wagolo` ; 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 `#` au-dessus d'elle, plan du fichier, références et implémentation d'un appel, recherche d'un symbole dans le projet, diagnostic d'un fichier qui ne s'analyse pas et d'un commentaire à la C — et un test qui vérifie que la définition de type, que `golo lsp` n'annonce pas, répond bien « rien » ; si un futur `golo` l'apprend, ce test le dira, comme il l'a dit quand GoloScript v0.2.0 a appris les références, les implémentations et les symboles du projet. Ces tests **se sautent eux-mêmes** quand `golo` n'est pas installé : un clone sans GoloScript 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 Golo` 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 Golo 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.5.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) |