test-coverage

Use git diff to identify changed source files, read each file's public API and branches, then check existing tests for coverage gaps. Write only the tests needed to cover untested functions, error cases, and boundary conditions.

Analyze existing tests first to find uncovered branches, then write table-driven or parameterized tests where multiple inputs exercise the same code path. Each test should cover a distinct behavior, targeting the public interface rather than implementation details.

Yes, the workflow is language-agnostic and adapts to repo conventions such as foo_test.go, test_foo.py, or foo.test.ts. It runs coverage with the appropriate tooling like go test -cover, pytest --cov, or npm test.

Yes, always check for shared utilities in locations like __tests__/, conftest.py, or __mocks__/ before writing new setup code. If a needed helper is missing, add it to the shared location rather than inline in the test file.

Skip generated code, third-party libraries, and trivial getters or setters, as testing them adds maintenance cost without meaningful coverage. Focus on business logic, error handling, and non-obvious branches.