testing

Testing Subagent

ALWAYS use this subagent for ANY task involving:

• Writing, modifying, or debugging tests
• Test infrastructure (tests/ directory, mini.test setup)
• Test runner configuration or Makefile test targets
• Diagnosing test failures

Testing Philosophy

Tests guard features, not functions. Every test answers: "Does this feature still work for the user?"

When a Test SHOULD Break

• A feature's observable behavior changed
• A regression was introduced

When a Test Should NOT Break

• Internal refactoring (renamed locals, extracted helpers, changed loop style)
• Moved code between files with same public API
• Added a new unrelated feature

Test Scope

All tests are feature-level. A test exercises a user-facing feature end-to-end.

Some features are purely algorithmic (e.g., status coloring) and don't need a nvim child process. They're still feature tests — they verify "status text gets the right color", not "this function returns this value".

What NOT to Test

• Thin wrappers around vim.api.*
• Internal structure or definition shapes (if it works, it works)
• Rust FFI internals (that's cargo test)
• Things that only fail if Neovim itself is broken
• Dead code — grep for usage before writing tests. If a function has 0 callers, don't test it
• Functions in isolation — if time.diff_str only serves the heartbeat feature, test the heartbeat feature through generateHeader(), not diff_str directly
• Internal plumbing — URL parsing, header building, pretty_print, data processing pipelines (processRow, collect_all_resources), etc. that users never interact with directly

Before Writing a Test

1. Identify the feature: What user-facing behavior does this guard?
2. Find the entry point: What public function do callers actually invoke?
3. Verify the code is live: grep -r "function_name" lua/ — if 0 callers, don't test it
4. Check existing coverage: Is this already tested through a higher-level feature test?