lsp-hover-testing
Headless testing of Dingo transpiler LSP hover functionality.
Install
mkdir -p .claude/skills/lsp-hover-testing && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/3050" && unzip -o skill.zip -d .claude/skills/lsp-hover-testing && rm skill.zipInstalls to .claude/skills/lsp-hover-testing
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Automated LSP hover validation for Dingo transpiler. Use when testing hover functionality, validating position mappings, checking for hover drift, or debugging LSP issues after sourcemap changes.Key capabilities
- →Automate LSP hover validation for Dingo
- →Validate column and line mappings
- →Run headless regression tests for hover
- →Compare hover output against YAML specifications
How it works
The tool runs headless tests by sending LSP hover requests to the Dingo server and comparing the returned content against expected substrings defined in YAML files.
Inputs & outputs
When to use lsp-hover-testing
- →Validating column and line mappings for hover
- →Testing hover drift after sourcemap changes
- →Creating regression tests for Dingo LSP
- →Debugging transpiler mapping issues
About this skill
LSP Hover Testing Skill
Automated headless testing of LSP hover functionality for the Dingo transpiler. Replaces manual VS Code hover checks with reproducible, CI-compatible tests.
When to Use This Skill
- After making changes to sourcemap/position tracking code
- When debugging hover issues reported by users
- To validate that column/line mappings work correctly
- Before committing changes to
pkg/lsp/,pkg/sourcemap/, orpkg/transpiler/ - To create regression tests for hover functionality
Quick Start
# Build the tools first
go build -o dingo ./cmd/dingo
go build -o editors/vscode/server/bin/dingo-lsp ./cmd/dingo-lsp
go build -o lsp-hovercheck ./cmd/lsp-hovercheck
# Run hover tests
./lsp-hovercheck --spec "ai-docs/hover-specs/*.yaml"
# Verbose output for debugging
./lsp-hovercheck --spec ai-docs/hover-specs/http_handler.yaml --verbose
Spec File Format
Create YAML specs in ai-docs/hover-specs/:
file: examples/01_error_propagation/http_handler.dingo
cases:
- id: 1
line: 55 # 1-based line number
token: userID # Token to hover on
occurrence: 1 # Which occurrence (default: 1)
description: "LHS variable"
expect:
contains: "var userID string" # Must contain substring
# OR
containsAny: # Any of these
- "var userID"
- "userID string"
# OR
allowAny: true # Accept any result (skip assertion)
Assertion Types
| Type | Description | Example |
|---|---|---|
contains | Must contain substring | contains: "func foo" |
containsAny | Any of listed substrings | containsAny: ["func", "method"] |
notContains | Must not contain | notContains: "error" |
allowAny | Skip assertion, just record | allowAny: true |
Output Format
http_handler.yaml:
------------------------------------------------------------
1: works
2: works
3: expected "var r", got "func extractUserID..."
4: works
============================================================
Total: 3 passed, 1 failed
Creating New Test Specs
Step 1: Identify test positions
# Show line numbers
sed -n '50,70p' examples/01_error_propagation/http_handler.dingo | nl -ba
Step 2: Create spec file
cat > ai-docs/hover-specs/my_example.yaml << 'EOF'
file: examples/my_example/file.dingo
cases:
- id: 1
line: 10
token: myFunction
description: "Function name hover"
expect:
contains: "func myFunction"
EOF
Step 3: Run and iterate
./lsp-hovercheck --spec ai-docs/hover-specs/my_example.yaml --verbose
Debugging Failed Tests
When a test fails, check:
- Column position: Is the token found at the right column?
- Tab handling: Lines starting with tabs may have offset issues
- Transformed lines: Error prop lines map to different Go positions
- LSP readiness: Increase
--retriesif hover returns empty
Verbose debug output
./lsp-hovercheck --spec ai-docs/hover-specs/http_handler.yaml --verbose
Shows:
- Exact LSP request/response JSON
- Computed column positions
- Hover content returned
Known Limitations
VS Code vs Automated Differences
The automated test may show different results than VS Code due to:
- Tab character handling differences
- LSP initialization timing
- VS Code extension preprocessing
Current Behavior (2025-12-14)
| Position Type | Automated Result | VS Code Result |
|---|---|---|
| Function names | Works | Works |
| Function arguments | Works | Shows function sig (bug) |
| LHS variables | Empty | Shows temp var (bug) |
File Locations
| File | Purpose |
|---|---|
cmd/lsp-hovercheck/ | Hover check tool source |
ai-docs/hover-specs/ | Test specification files |
editors/vscode/server/bin/dingo-lsp | LSP server binary |
CI Integration
Add to your CI pipeline:
- name: Build tools
run: |
go build -o dingo ./cmd/dingo
go build -o editors/vscode/server/bin/dingo-lsp ./cmd/dingo-lsp
go build -o lsp-hovercheck ./cmd/lsp-hovercheck
- name: Run hover tests
run: ./lsp-hovercheck --spec "ai-docs/hover-specs/*.yaml"
Related Files
When not to use it
- →When relying on VS Code extension preprocessing for test results
Prerequisites
Limitations
- →Automated results may differ from VS Code due to tab handling
- →LSP initialization timing can affect test reliability
How it compares
It replaces manual VS Code hover verification with reproducible, CI-compatible automated testing.
Compared to similar skills
lsp-hover-testing side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| lsp-hover-testing (this skill) | 1 | 8mo | Review | Intermediate |
| go-dev-guidelines | 14 | 9mo | No flags | Intermediate |
| code-formatting | 1 | 2mo | No flags | Beginner |
| tidb-test-guidelines | 2 | 28d | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by MadAppGang
View all by MadAppGang →You might also like
go-dev-guidelines
jumppad-labs
This skill should be used when writing, refactoring, or testing Go code. It provides idiomatic Go development patterns, TDD-based workflows, project structure conventions, and testing best practices using testify/require and mockery. Activate this skill when creating new Go features, services, packages, tests, or when setting up new Go projects.
code-formatting
openshift
MANDATORY: When writing Go tests, you MUST use 'When...it should...' format for ALL test names. When writing any Go code, you MUST remind user to run 'make lint-fix' and 'make verify'. These are non-negotiable HyperShift requirements.
tidb-test-guidelines
pingcap
Decide where to place TiDB tests and how to write them (basic structure, naming, testdata usage). Use when asked about test locations, writing conventions, shard_count limits, casetest categorization, or when reviewing test changes in code review.
go-rig
mudrii
Use this skill when building, reviewing, or refactoring Go code in this repository. It adds process discipline for TDD/ATDD, package boundaries, dependency injection, and review quality, and complements the always-on rules in AGENTS.md.
code-coverage
viknesh20-20
Analyzes test coverage, identifies untested code paths, and generates tests for the most critical uncovered areas. Use to improve test coverage before releases.
go-review-pr
JotJunior
Review all changes in the current branch against GOB project conventions before opening a PR. Diff-aware: only analyzes what changed, not the entire codebase. Triggers: \"review pr\", \"revisar pr\", \"pre-pr check\", \"review branch\", \"revisar branch\", \"checar antes do pr\", \"quality gate\".