Lancer les tests

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97

# Lancer les tests

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.

## Toute la suite

```bash
make test
```

C'est la commande unique documentée. Elle exécute `go test ./...` sur tous les paquets.

## Variantes

**Voir chaque test par son nom :**

```bash
make test-verbose
```

**Mesurer la couverture par paquet :**

```bash
make cover
```

**Un seul paquet :**

```bash
go test ./internal/gololang/
```

**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 :

```bash
go test -short ./...
```

**Tout ce qu'un commit devrait passer :**

```bash
make check
```

Cela enchaîne `go fmt`, `go vet` et les tests, dans cet ordre.

## Ce que la suite couvre

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.

Ce que ce dépôt teste est ce qui n'appartient qu'à lui :

- **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.
- **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`.
- **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.
- **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.
- **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.

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.

## Tester sur un turbo-core non publié

L'essentiel de Turbo Golo est turbo-core, et ce dépôt en dépend par version, depuis le proxy de modules :

```
require rickub.com/turbo-editors/turbo-core v0.5.0
```

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 :

```bash
go work init . ../turbo-core
make test
```

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 :

```bash
go list -f '{{.Dir}}' rickub.com/turbo-editors/turbo-core/app
```

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.

## Qualité du code

La suite de tests n'est pas toute la porte de qualité. Celle-ci se mesure à part :

```bash
python3 ~/.claude/skills/quality/scripts/quality_report.py --workspace .
```

Elle écrit un rapport sous `.quality/` et sort en erreur si la porte échoue.

## Voir aussi

- Pourquoi les tests ont cette forme : [Architecture](../explanation/architecture.md)
- Toutes les cibles make : [référence de la ligne de commande](../reference/cli.md)