# Lancer les tests

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.

## 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/golang/
```

**Sans lancer de serveur de langage.** Un test de `internal/golang` démarre un vrai `gopls` s'il en trouve un. Pour le sauter :

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

**Avec le détecteur de compétition.** Le client LSP est concurrent : cela vaut la peine avant d'y toucher.

```bash
go test -race ./...
```

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

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.

## Tester sur un turbo-core non publié

L'essentiel de Turbo Go 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.2.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)