lsp-test-correlation
Über
Diese Fähigkeit identifiziert und führt nur die spezifischen Tests aus, die eine geänderte Quelldatei abdecken, und vermeidet die Ausführung des gesamten Testsuites. Sie ist ideal für die Validierung nach Bearbeitungen oder für Pre-Commit-Prüfungen, um schnelles, gezieltes Feedback zu erhalten. Sie erfordert den Agent-LSP-MCP-Server und nutzt LSP-Funktionen, um Quelldateien ihren entsprechenden Tests zuzuordnen.
Schnellinstallation
Claude Code
Empfohlennpx skills add blackwell-systems/agent-lsp -a claude-code/plugin add https://github.com/blackwell-systems/agent-lspgit clone https://github.com/blackwell-systems/agent-lsp.git ~/.claude/skills/lsp-test-correlationKopieren Sie diesen Befehl und fügen Sie ihn in Claude Code ein, um diese Fähigkeit zu installieren
Dokumentation
Requires the agent-lsp MCP server.
lsp-test-correlation
Discover which tests cover a source file, then run only those tests. Faster than running the full suite when you've changed one or two files and want targeted feedback.
When to use
- After editing a source file: "Which tests do I need to run for this change?"
- Before committing: run only the tests that cover what you touched
- Debugging a failure: find which test file corresponds to a broken source file
- Code review: understand what test coverage exists for a file before merging
Use /lsp-verify instead when you want to run the full suite and check all
three layers (diagnostics + build + tests). Use this skill when you want fast,
scoped test execution.
Workflow
Step 1 — Find correlated test files
Call get_tests_for_file for each edited source file:
mcp__lsp__get_tests_for_file({ "file_path": "/abs/path/to/source.go" })
Returns the test files that correspond to the source file. For multiple edited files, call once per file.
If no test files are returned: the source file may have no dedicated test file, or the mapping is not resolvable (e.g. integration tests in a separate directory). See Step 2 for fallback.
Step 2 — Enumerate test functions (fallback or enrichment)
If get_tests_for_file returns test files, use find_symbol to list
the test functions defined in those files:
mcp__lsp__find_symbol({ "query": "Test" })
Filter results to the correlated test files from Step 1. This gives you the specific test function names to run rather than the whole test file.
Fallback (no test files found): query find_symbol for test
functions that contain the changed symbol's name:
mcp__lsp__find_symbol({ "query": "Test<ChangedFunctionName>" })
This catches cases where get_tests_for_file misses indirect coverage.
Step 3 — Report the correlation map
Before running, report what was found:
## Test correlation for <file>
Source file: internal/tools/analysis.go
Test files:
→ internal/tools/analysis_test.go
Tests: TestHandleGetCodeActions, TestHandleGetCompletions, TestHandleGetDocumentSymbols
No correlated test files found for: internal/lsp/normalize.go
→ Fallback: TestNormalizeCompletion, TestNormalizeDocumentSymbols (from workspace symbol search)
If the user provided run=true or asks to run, proceed to Step 4. Otherwise
stop here and let the user decide.
Step 4 — Run correlated tests
Run only the correlated test files or functions. Scope as tightly as possible:
Go — run specific package:
mcp__lsp__run_tests({ "workspace_dir": "<root>", "test_filter": "TestHandleGetCodeActions|TestHandleGetCompletions" })
If run_tests does not support test_filter, pass the package path instead of
the workspace root to narrow scope. The test output will be smaller and faster
than running ./....
Output handling: If test output is large, do not read it in full. Search for failures:
grep -E "^(FAIL|--- FAIL)" <output_file>
Step 5 — Report results
## Test Results
Ran 3 tests in internal/tools/analysis_test.go
PASSED (2):
TestHandleGetCodeActions
TestHandleGetCompletions
FAILED (1):
TestHandleGetDocumentSymbols — expected 3 symbols, got 2 (analysis_test.go:87)
Recommendation: Fix TestHandleGetDocumentSymbols before committing.
Multi-file workflow
For changes spanning multiple source files:
- Call
get_tests_for_filefor each changed file in parallel. - Deduplicate the resulting test files (the same test file may cover multiple source files).
- Report the full correlation map before running.
- Run the deduplicated test set once.
## Test correlation for 3 changed files
internal/tools/analysis.go → internal/tools/analysis_test.go
internal/lsp/client.go → internal/lsp/client_test.go, internal/lsp/client_completion_test.go
internal/resources/resources.go → (no dedicated test file)
Deduplicated test files to run: 3
Decision guide
| Situation | Action |
|---|---|
get_tests_for_file returns test files | Use those; enumerate functions via find_symbol |
| No test files returned | Fallback to find_symbol with changed symbol names |
| Test files found but no matching test functions | Report gap — this source file may lack unit test coverage |
| More than 10 test files returned | Don't run all; use /lsp-verify for full suite instead |
| Test fails | Run /lsp-verify for full diagnostic picture |
Example
# "I edited internal/tools/symbol_source.go — which tests should I run?"
get_tests_for_file(file_path="/repo/internal/tools/symbol_source.go")
→ internal/tools/symbol_source_test.go
find_symbol(query="TestGetSymbolSource")
→ TestGetSymbolSource_ContainsPosition (line 12)
→ TestGetSymbolSource_FindInnermost (line 34)
→ TestGetSymbolSource_PositionPattern (line 67)
# Report correlation, then run:
run_tests(workspace_dir="/repo", test_filter="TestGetSymbolSource")
→ 3 passed in 0.4s
GitHub Repository
Verwandte Skills
evaluating-llms-harness
TestenDiese Claude Skill führt den lm-evaluation-harness aus, um LLMs über 60+ standardisierte akademische Aufgaben wie MMLU und GSM8K zu benchmarken. Sie wurde für Entwickler entwickelt, um Modellqualität zu vergleichen, Trainingsfortschritt zu verfolgen oder akademische Ergebnisse zu berichten. Das Tool unterstützt verschiedene Backends, einschließlich HuggingFace- und vLLM-Modelle.
cloudflare-cron-triggers
TestenDiese Fähigkeit bietet umfassendes Wissen zur Implementierung von Cloudflare Cron Triggers, um Workers mithilfe von Cron-Ausdrücken zu planen. Sie behandelt das Einrichten periodischer Aufgaben, Wartungsjobs und automatisierter Workflows, während häufige Probleme wie ungültige Cron-Ausdrücke und Zeitzonenprobleme behandelt werden. Entwickler können sie zum Konfigurieren geplanter Handler, zum Testen von Cron-Triggers und zur Integration mit Workflows und Green Compute verwenden.
webapp-testing
TestenDiese Claude Skill bietet ein Playwright-basiertes Toolkit zum Testen lokaler Webanwendungen durch Python-Skripte. Es ermöglicht Frontend-Verifizierung, UI-Debugging, Screenshot-Aufnahme und Log-Einblick bei gleichzeitiger Verwaltung von Server-Lebenszyklen. Nutzen Sie es für Browser-Automatisierungsaufgaben, führen Sie Skripte jedoch direkt aus, anstatt deren Quellcode zu lesen, um Kontextverschmutzung zu vermeiden.
finishing-a-development-branch
TestenDiese Fähigkeit unterstützt Entwickler dabei, abgeschlossene Arbeiten zu finalisieren, indem sie testet, ob Tests bestehen, und dann strukturierte Integrationsoptionen präsentiert. Sie leitet den Workflow für das Zusammenführen von Code, das Erstellen von PRs oder das Bereinigen von Branches nach Abschluss der Implementierung. Nutzen Sie sie, wenn Ihr Code bereit und getestet ist, um den Entwicklungsprozess systematisch abzuschließen.
