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
96
97

# How to run the tests

This guide shows how to run and read Turbo JS'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/jslang/
```

**Without starting a language server, and without building the editor.** The tests in `internal/jslang/editor_test.go` whose names end in `WithRealServer` start a real `typescript-language-server` when they find one, and the installer tests at the root compile the whole editor. To skip both:

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

**With the race detector.** The LSP client is concurrent, so this is worth running before touching anything that talks to 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. `internal/jslang/editor_test.go` assembles a whole Turbo JS on tcell's `SimulationScreen` — a real `Screen` that draws into memory — opens a file and checks the colouring, the menu bar and the hot keys on the picture a terminal would actually show. `scan_test.go` holds the scanner to every construct it colours and every one it must refuse — `0xFF` and `.5` as numbers, a `/` that divides rather than opening a regular expression, a block comment that does not nest.

The tests named `…WithRealServer` start the real `typescript-language-server`: they complete text that exists only in the buffer, go to a definition, list every reference, find a class's subclasses as its implementations and an instance's class as its type definition, read the JSDoc comment a hover shows, list a file's symbols, search the project for one, and wait for a diagnostic on a file that does not parse. Nine questions, nine tests — so the day the server stops answering one of them, the documentation gets revisited rather than quietly going stale.

All of them **skip themselves** when `typescript-language-server` is not installed, and under `-short`, so a checkout without the server still has a green suite.

## Testing against an unreleased turbo-core

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

```
require rickub.com/turbo-editors/turbo-core v0.8.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`; both are gitignored, so they 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)