Comment 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

# Comment lancer les tests

Ce guide montre comment vérifier le projet avant un commit ou une merge request. Il suppose les prérequis de développement installés (voir [Comment développer l'application](developper-l-application.md)) et un terminal ouvert à la racine du dépôt.

## Lancer tous les tests

```bash
make check
```

La commande lance les linters (`make lint`), puis tous les tests qui n'ont besoin ni d'un vrai agent, ni d'un modèle, ni du réseau (`make test`). Un passage réussi se termine par :

```text
14 passed, 0 failed
all licence header tests passed
```

Avant de fusionner, `make verify` la lance avec la vérification des bindings : voir [Vérifier une modification avant de la fusionner](verifier-avant-de-fusionner.md).

## Lancer une partie

| Pour vérifier | Commande |
| --- | --- |
| Les packages Go | `make test-go`, ou `go test -race ./internal/agents -run Limit -v` pour un test |
| Le frontend (vitest), dont le contraste WCAG des couleurs du thème | `make test-frontend` |
| L'outillage shell (agents.sh, en-têtes de licence, noms des paquets, tag de release) | `make test-scripts` |
| Le lint Go (golangci-lint, épinglé dans `tools/go.mod`) | `make lint-go` |
| Les types du frontend et les avertissements Svelte | `make lint-frontend` |
| Les en-têtes de licence | `make lint-headers` |
| Les bindings TypeScript commités sont à jour | `make bindings-check` |

## Lancer les tests avec les vrais agents

```bash
make test-real
```

La commande lance les tests compilés avec le tag `realagents` : la poignée de main ACP avec Alice, Riker qui demande la permission avant d'exécuter une commande, Bob qui lit la réponse d'Alice dans un channel, et Alice qui se souvient d'une conversation après un redémarrage (`internal/acp`, `internal/channels`). Comptez environ une minute. Ils ont besoin de `mm` (ou `MM_BIN`) et de llmman, et ne démarrent les agents que via `scripts/agents.sh` : la limite de deux agents et le déchargement s'appliquent.

## Lancer les tests du workspace dans un conteneur

Les tests de contrat du workspace (`internal/workspace`) tournent aussi dans un vrai conteneur quand Docker et l'image `alpine:3.22` sont présents ; sinon, ces tests sont ignorés. Pour les inclure :

```bash
docker pull alpine:3.22
go test ./internal/workspace
```

Pour les lancer aussi dans une sandbox sbx, nommez-en une démarrée :

```bash
SIDEKICKS_TEST_SBX=<sandbox> go test -count=1 -run TestSandboxWorkspace ./internal/workspace
```

## Variantes

- **`go test` se plaint de `frontend/dist`** : le binaire Go embarque le frontend construit. `make test-go` le construit s'il manque ; avec `go test` seul, lancez `make frontend` une fois.
- **Les spikes** (`spikes/`) sont des modules séparés, non testés ; vérifiez-les avec `go vet .` dans chaque dossier.
- **`make: warning: Clock skew detected`** apparaît quand le dépôt est dans un dossier partagé avec une autre machine ; le résultat n'en dépend pas.

## Voir aussi

- Toutes les cibles → [Référence : commandes](../reference/commandes.md)
- L'outillage testé → [Référence : scripts/agents.sh](../reference/script-agents.md)