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 JS. 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/jslang/
```

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

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

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 JS 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.8.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)