How to run the 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

# How to run the tests

This guide shows how to run and read Turbo Go's test suite. It assumes you have a checkout and Go 1.26 or later.

## The whole suite

```bash
make test
```

That is the single documented command. It runs `go test ./...` across every package.

## Variants

**See each test by name:**

```bash
make test-verbose
```

**Measure coverage per package:**

```bash
make cover
```

**One package only:**

```bash
go test ./internal/golang/
```

**Without starting a language server.** One test in `internal/golang` starts a real `gopls` when it finds one. To skip it:

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

**With the race detector.** The LSP client is concurrent, so this is worth running before touching it:

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

**Everything a commit should pass:**

```bash
make check
```

This runs `go fmt`, `go vet` and the tests, in that order.

## What the suite covers

No test needs a real terminal. The widgets and the editor are drawn onto tcell's `SimulationScreen` — a real `Screen` that draws into memory — so the assertions are made on the picture a terminal would actually show. The LSP client is driven against a language server running in the same process, over an in-memory pipe.

The one exception is `TestAgainstRealGopls`, which starts the real thing. It **skips itself** when `gopls` is not installed, so a checkout without one still has a green suite.

## Testing against an unreleased turbo-core

Most of Turbo Go is turbo-core, and this repository depends on it by version, from the module proxy:

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

A change made in a turbo-core checkout beside this one is therefore invisible here until it is published. To test it before that, make a workspace:

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

Every import of the library now resolves to that checkout. Nothing in `go.mod` or `go.sum` changes, so there is no edit to undo. Check it took effect — this is the mistake worth guarding against, because everything still builds and still passes if it did not:

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

The answer should be your checkout, not a path under `pkg/mod`. When you are done, `rm go.work go.work.sum`; it is gitignored, so it cannot be committed by accident.

## Code quality

The test suite is not the whole gate. Quality is measured separately:

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

It writes a report under `.quality/` and exits non-zero if the gate fails.

## See also

- Why the tests are shaped this way: [Architecture](../explanation/architecture.md)
- Every make target: [command line reference](../reference/cli.md)