| 📦 Turbo Golo d710c1b k33g 12h ago | 1 | # How to run the tests |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | ## The whole suite |
| 6 | |
| 7 | ```bash |
| 8 | make test |
| 9 | ``` |
| 10 | |
| 11 | That is the single documented command. It runs `go test ./...` across every package. |
| 12 | |
| 13 | ## Variants |
| 14 | |
| 15 | **See each test by name:** |
| 16 | |
| 17 | ```bash |
| 18 | make test-verbose |
| 19 | ``` |
| 20 | |
| 21 | **Measure coverage per package:** |
| 22 | |
| 23 | ```bash |
| 24 | make cover |
| 25 | ``` |
| 26 | |
| 27 | **One package only:** |
| 28 | |
| 29 | ```bash |
| 30 | go test ./internal/gololang/ |
| 31 | ``` |
| 32 | |
| 33 | **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: |
| 34 | |
| 35 | ```bash |
| 36 | go test -short ./... |
| 37 | ``` |
| 38 | |
| 39 | **With the race detector.** The LSP client is concurrent, so this is worth running before touching anything that talks to it: |
| 40 | |
| 41 | ```bash |
| 42 | go test -race ./... |
| 43 | ``` |
| 44 | |
| 45 | **Everything a commit should pass:** |
| 46 | |
| 47 | ```bash |
| 48 | make check |
| 49 | ``` |
| 50 | |
| 51 | This runs `go fmt`, `go vet` and the tests, in that order. |
| 52 | |
| 53 | ## What the suite covers |
| 54 | |
| 55 | 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. |
| 56 | |
| 57 | 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. |
| 58 | |
| 59 | All of them **skip themselves** when `golo` is not installed, and under `-short`, so a checkout without the interpreter still has a green suite. |
| 60 | |
| 61 | ## Testing against an unreleased turbo-core |
| 62 | |
| 63 | Most of Turbo Golo is turbo-core, and this repository depends on it by version, from the module proxy: |
| 64 | |
| 65 | ``` |
| 66 | require rickub.com/turbo-editors/turbo-core v0.5.0 |
| 67 | ``` |
| 68 | |
| 69 | 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: |
| 70 | |
| 71 | ```bash |
| 72 | go work init . ../turbo-core |
| 73 | make test |
| 74 | ``` |
| 75 | |
| 76 | 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: |
| 77 | |
| 78 | ```bash |
| 79 | go list -f '{{.Dir}}' rickub.com/turbo-editors/turbo-core/app |
| 80 | ``` |
| 81 | |
| 82 | 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. |
| 83 | |
| 84 | ## Code quality |
| 85 | |
| 86 | The test suite is not the whole gate. Quality is measured separately: |
| 87 | |
| 88 | ```bash |
| 89 | python3 ~/.claude/skills/quality/scripts/quality_report.py --workspace . |
| 90 | ``` |
| 91 | |
| 92 | It writes a report under `.quality/` and exits non-zero if the gate fails. |
| 93 | |
| 94 | ## See also |
| 95 | |
| 96 | - Why the tests are shaped this way: [Architecture](../explanation/architecture.md) |
| 97 | - Every make target: [command line reference](../reference/cli.md) |