| 📦 Turbo Go 3d7798b k33g 13h ago | 1 | # Lancer les tests |
| 2 | |
| 3 | Ce guide montre comment exécuter et lire la suite de tests de Turbo Go. 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/golang/ |
| 31 | ``` |
| 32 | |
| 33 | **Sans lancer de serveur de langage.** Un test de `internal/golang` démarre un vrai `gopls` s'il en trouve un. Pour le sauter : |
| 34 | |
| 35 | ```bash |
| 36 | go test -short ./... |
| 37 | ``` |
| 38 | |
| 39 | **Avec le détecteur de compétition.** Le client LSP est concurrent : cela vaut la peine avant d'y toucher. |
| 40 | |
| 41 | ```bash |
| 42 | go test -race ./... |
| 43 | ``` |
| 44 | |
| 45 | **Tout ce qu'un commit devrait passer :** |
| 46 | |
| 47 | ```bash |
| 48 | make check |
| 49 | ``` |
| 50 | |
| 51 | Cela enchaîne `go fmt`, `go vet` et les tests, dans cet ordre. |
| 52 | |
| 53 | ## Ce que la suite couvre |
| 54 | |
| 55 | Aucun test n'a besoin d'un vrai terminal. Les widgets et l'éditeur sont dessinés 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. Le client LSP est testé contre un serveur de langage tournant dans le même processus, à travers un tube en mémoire. |
| 56 | |
| 57 | La seule exception est `TestAgainstRealGopls`, qui démarre le vrai serveur. Il **se saute lui-même** quand `gopls` n'est pas installé : un clone sans serveur de langage a donc quand même une suite verte. |
| 58 | |
| 59 | ## Tester sur un turbo-core non publié |
| 60 | |
| 61 | L'essentiel de Turbo Go est turbo-core, et ce dépôt en dépend par version, depuis le proxy de modules : |
| 62 | |
| 63 | ``` |
| 64 | require rickub.com/turbo-editors/turbo-core v0.2.0 |
| 65 | ``` |
| 66 | |
| 67 | 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 : |
| 68 | |
| 69 | ```bash |
| 70 | go work init . ../turbo-core |
| 71 | make test |
| 72 | ``` |
| 73 | |
| 74 | 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 : |
| 75 | |
| 76 | ```bash |
| 77 | go list -f '{{.Dir}}' rickub.com/turbo-editors/turbo-core/app |
| 78 | ``` |
| 79 | |
| 80 | 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. |
| 81 | |
| 82 | ## Qualité du code |
| 83 | |
| 84 | La suite de tests n'est pas toute la porte de qualité. Celle-ci se mesure à part : |
| 85 | |
| 86 | ```bash |
| 87 | python3 ~/.claude/skills/quality/scripts/quality_report.py --workspace . |
| 88 | ``` |
| 89 | |
| 90 | Elle écrit un rapport sous `.quality/` et sort en erreur si la porte échoue. |
| 91 | |
| 92 | ## Voir aussi |
| 93 | |
| 94 | - Pourquoi les tests ont cette forme : [Architecture](../explanation/architecture.md) |
| 95 | - Toutes les cibles make : [référence de la ligne de commande](../reference/cli.md) |