turbo-editors/turbo-pythonpublic Fork 0
v1.0.0
Commits
Clone
git clone https://git.rickub.com/turbo-editors/turbo-python.git
git clone ssh://git@rickub.com/turbo-editors/turbo-python.git

Host key fingerprint (ed25519): SHA256:iycHnxEyq0Q7uyVpB7JlznP0G7JrTPXLYRcAU5CSLhc — verify it before your first connect.

📦 Turbo Python 6fc62ea · on v1.0.0 · k33g · 8h ago
run-the-tests.md · 95 lines · 2.7 KBmarkdown
Blame HistoryOpen raw

How to run the tests

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

The whole suite

make test

That is the single documented command. It runs uv run pytest across every package.

Variants

See each test by name:

make test-verbose

Measure coverage per package:

make cover

One package only:

go test ./internal/buffer/

Without starting a language server. One test in internal/lsp starts a real pylsp when it finds one. To skip it:

go test -short ./...

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

go test -race ./internal/lsp/

Everything a commit should pass:

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 pylsp is not installed, so a checkout without one still has a green suite.

Testing against an unreleased turbo-core

Most of Turbo Python 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:

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:

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:

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

 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 Python'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 `uv run pytest` 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/buffer/
```

**Without starting a language server.** One test in `internal/lsp` starts a real `pylsp` 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 ./internal/lsp/
```

**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 `pylsp` is not installed, so a checkout without one still has a green suite.

## Testing against an unreleased turbo-core

Most of Turbo Python 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)