# How to run the tests

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

**Without starting a language server, and without building the editor.** The tests in `internal/gololang/editor_test.go` whose names end in `WithRealGoloLSP` start a real `golo lsp` 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/gololang/editor_test.go` assembles a whole Turbo Golo 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` as a number, a leading dot, `---` closing a block comment.

The tests named `…WithRealGoloLSP` start the real interpreter in language-server mode: they complete text that exists only in the buffer, go to a definition, read a hover, list a file's symbols, find the references and the implementation of a call, search the project for a symbol, and wait for a diagnostic on a file that does not parse and on one with a C-style comment. Two more pin what the toolchain is: `TestTheScannersTablesMatchWhatTheServerOffers` checks the scanner's keyword and builtin tables against what `golo lsp` actually offers, and `TestGoloLSPDoesNotAnswerTypeDefinitionWithRealGoloLSP` fails the day a future `golo` starts answering type definitions — so the documentation gets revisited rather than quietly going stale, as it was when GoloScript v0.2.0 started answering references, implementations and project-wide symbols.

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

## Testing against an unreleased turbo-core

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

```
require rickub.com/turbo-editors/turbo-core v0.5.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)