How to run the tests

This guide shows how to run turbo-core's test suite and what it covers. It assumes a checkout and Go 1.26 or later.

The one command

make test

That is go test ./... over every package. It needs no setup, no network and no language server: everything it drives is either a pure function or a simulated terminal.

Steps

Run the whole suite

make test

You should see one ok line per package, fifteen of them.

Run it under the race detector

make race

The editor has goroutines in three places — the language-server read loop, the terminal's pty reader, and a running tool's output — and every one of them has had a race in it at some point. Run this before committing anything that touches them.

See what is covered

make cover

Run one package

go test ./syntax/
go test -run TestRegister ./syntax/

See the commands themselves

make help

Variants

You changed a scanner

go test ./syntax/ is the fast loop. Then run the whole suite, because editor and app both draw through it.

You changed something with a goroutine behind it

Use make race, not make test. A data race in a constructor that starts a goroutine hid here for a whole feature, because a shell takes longer to produce output than an assignment takes to run.

A test passed the moment you wrote it

Break the code it covers and watch it fail. This project has more than one recorded case of a test that passed because it tested nothing — a callback nobody wired, a step the test itself performed. A new test that has never failed has not been tested.

 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


# How to run the tests

This guide shows how to run turbo-core's test suite and what it covers. It assumes a checkout and Go 1.26 or later.

## The one command

```bash
make test
```

That is `go test ./...` over every package. It needs no setup, no network and no language server: everything it drives is either a pure function or a simulated terminal.

## Steps

### Run the whole suite

```bash
make test
```

You should see one `ok` line per package, fifteen of them.

### Run it under the race detector

```bash
make race
```

The editor has goroutines in three places — the language-server read loop, the terminal's pty reader, and a running tool's output — and every one of them has had a race in it at some point. Run this before committing anything that touches them.

### See what is covered

```bash
make cover
```

### Run one package

```bash
go test ./syntax/
go test -run TestRegister ./syntax/
```

### See the commands themselves

```bash
make help
```

## Variants

### You changed a scanner

`go test ./syntax/` is the fast loop. Then run the whole suite, because `editor` and `app` both draw through it.

### You changed something with a goroutine behind it

Use `make race`, not `make test`. A data race in a constructor that starts a goroutine hid here for a whole feature, because a shell takes longer to produce output than an assignment takes to run.

### A test passed the moment you wrote it

Break the code it covers and watch it fail. This project has more than one recorded case of a test that passed because it tested nothing — a callback nobody wired, a step the test itself performed. A new test that has never failed has not been tested.

## See also

- Running an editor's own tests: each editor's `how-to/run-the-tests.md`
- What the packages are: [packages reference](../reference/packages.md)