diff --git a/README.md b/README.md index 87a4d90..b435a65 100644 --- a/README.md +++ b/README.md @@ -79,6 +79,7 @@ Additional keymaps: ## Runner architecture Runners are standalone Lua modules. All runner modules are expected to implement the full interface so every command and keymap works. +All functions are required (including the previously optional ones) and listing output must be streamed. Required functions: - `is_test_file` @@ -87,6 +88,9 @@ Required functions: - `build_file_command` - `build_all_command` - `build_failed_command` +- `parse_results` +- `output_parser` (must stream listing output via `on_line`) +- `parse_test_output` - `collect_failed_locations` No runner for your environment exists? No problem: use `runners-agents.md` to guide an AI-assisted runner implementation tailored to your stack. @@ -100,6 +104,8 @@ No runner for your environment exists? No problem: use `runners-agents.md` to gu ## Development +Runner development guidelines, including required data formats for keymaps, tests (`run_test.sh`), and Gitea CI (Neovim AppImage on ARM runners), are documented in `runner-agents.md`. + Tests are written with `plenary.nvim` / `busted`. Mocks and stubs are allowed. Run tests: diff --git a/runner-agents.md b/runner-agents.md index 86f7a19..287504a 100644 --- a/runner-agents.md +++ b/runner-agents.md @@ -13,7 +13,7 @@ implementieren muss, damit alle Commands vollständig unterstützt werden. - Beispiel: `lua/test-samurai-go-runner/init.lua` -> `require("test-samurai-go-runner")`. - `lua/init.lua` wäre `require("init")` und ist kollisionsanfällig; vermeiden. -## Pflichtfunktionen (volle Command-Unterstützung) +## Pflichtfunktionen (volle Command- und Keymap-Unterstützung) - `is_test_file(bufnr) -> boolean` - Wird für die Runner-Auswahl genutzt. @@ -29,10 +29,18 @@ implementieren muss, damit alle Commands vollständig unterstützt werden. - Für `TSamAll`. - `build_failed_command(last_command, failures, scope_kind) -> command_spec` - Für `TSamFailedOnly`. +- `parse_results(output) -> results` + - Fallback-Parser für vollständigen Output. +- `output_parser() -> { on_line, on_complete }` + - Muss Streaming unterstützen (Listing wird live befüllt). +- `parse_test_output(output) -> table` + - Detail-Ausgabe pro Test (Detail-Float und `` im Listing). +- `collect_failed_locations(failures, command, scope_kind) -> items` + - Quickfix-Unterstützung (Keymap `qn`). ## Output-Parsing (Listing + Summary) -Genau eine der folgenden Varianten muss vorhanden sein: +Beide Varianten müssen vorhanden sein: - `parse_results(output) -> results` - `results` muss enthalten: @@ -46,6 +54,9 @@ Genau eine der folgenden Varianten muss vorhanden sein: - oder `output_parser() -> { on_line, on_complete }` - `on_line(line, state)` kann `results` liefern (siehe oben). - `on_complete(output, state)` kann `results` liefern (siehe oben). + - `on_line` muss Ergebnisse liefern, damit das Listing-Float immer gestreamt wird. + +Hinweis: `parse_results` darf intern `output_parser().on_complete` nutzen, aber beide Funktionen müssen existieren. ## Listing-Gruppierung fuer Parent/Subtests @@ -78,6 +89,25 @@ Genau eine der folgenden Varianten muss vorhanden sein: - `spec` (von `find_nearest`): - Muss mindestens `file` enthalten, z. B.: - `{ file = "...", cwd = "...", test_name = "...", full_name = "...", kind = "..." }` +- `results` (für Listing-Float + Keymaps): + - `{ passes = { "Name1", ... }, failures = { "Name2", ... }, skips = { "Name3", ... } }` + - Optional: `display = { passes = { "DisplayName1", ... }, failures = { "DisplayName2", ... }, skips = { "DisplayName3", ... } }` + - `failures` steuert `[ FAIL ]`-Zeilen im Listing und wird von `nf`/`pf` genutzt. +- `items` (für Quickfix): + - `{ { filename = "...", lnum = 1, col = 1, text = "..." }, ... }` + - Wird von `qn` verwendet. + +## Keymaps (Datenlieferung) + +- `nf` / `pf` + - benötigt `[ FAIL ]`-Einträge im Listing. + - Runner muss `results.failures` (und optional `display.failures`) liefern. +- `qn` + - springt in die Quickfix-Liste. + - Runner muss `collect_failed_locations` implementieren und gültige `items` liefern. +- `` im Listing + - öffnet Detail-Float. + - Runner muss `parse_test_output` liefern und Testnamen konsistent zu `results.*` halten. ## Optional empfohlene Metadaten @@ -126,6 +156,17 @@ function runner.parse_results(output) return { passes = {}, failures = {}, skips = {}, display = { passes = {}, failures = {}, skips = {} } } end +function runner.output_parser() + return { + on_line = function(_line, _state) + return nil + end, + on_complete = function(_output, _state) + return runner.parse_results(_output) + end, + } +end + function runner.parse_test_output(output) return {} end @@ -145,21 +186,33 @@ return runner - build_file_command implementiert - build_all_command implementiert - build_failed_command implementiert -- parse_results oder output_parser implementiert +- parse_results implementiert +- output_parser implementiert (Streaming) - parse_test_output implementiert - collect_failed_locations implementiert - command_spec `{ cmd, cwd }` korrekt zurückgegeben ## Projekt- und Prozessanforderungen -- Eine englischsprachige `README.md` ist zu erstellen. - - Sie muss bei jedem weiteren Prompt aktualisiert werden, wenn die Aenderungen es erfordern. +- Rolle: **TDD-first Entwickler**. + - Jede neue Funktion, jedes neue Kommando und jede Verhaltensänderung muss durch Tests abgesichert sein. + - Nach jeder Code-Änderung Tests via `bash run_test.sh` ausführen und bei Fehlern korrigieren, bis alles grün ist. +- **Nicht raten**: + - Bei unklaren oder mehrdeutigen Anforderungen Arbeit stoppen und Klarstellung verlangen. + - TODO/NOTE im Code ist zulässig, stilles Raten nicht. +- **Keine stillen Änderungen**: + - Bestehende Features dürfen nicht unbemerkt geändert oder ersetzt werden. + - Notwendige Anpassungen zur Koexistenz mehrerer Features müssen klar erkennbar sein. +- Antworten immer auf Deutsch. +- Eine englischsprachige `README.md` ist zu erstellen und wird bei Änderungen automatisch aktualisiert. - TDD-Vorgaben (aus `AGENTS.md`) uebernehmen: - Neue Funktionen/Commands/Verhaltensaenderungen muessen getestet werden. - Tests nach jeder Code-Aenderung ausfuehren. - Im Runner erstellter Quellcode ist ebenfalls zu testen. - - Eine eigene `run_test.sh` darf im Runner-Repo angelegt werden. + - Eine eigene `run_test.sh` wird im Runner-Repo angelegt. - Eine Gitea-Action ist zu erstellen, die bei jedem Push die Tests ausfuehrt. + - Neovim wird per AppImage installiert (kein `apt`). + - Runner laeuft auf `gitea-act-runner` mit Raspberry Pi 5 (ARM). - Beispiel (anpassbarer Workflow): ```yaml @@ -176,6 +229,11 @@ jobs: steps: - name: Checkout uses: actions/checkout@v4 + - name: Install Neovim (AppImage) + run: | + curl -L -o nvim.appimage https://github.com/neovim/neovim/releases/download/v0.11.4/nvim.appimage + chmod +x nvim.appimage + sudo mv nvim.appimage /usr/local/bin/nvim - name: Run tests run: bash run_test.sh ```