Write tests for untested code
Point Pier at a module with no coverage. It reads the behaviour, writes tests that match your existing style, and runs them to prove they pass.
› internal/tax/calc.go has no tests. Write some that match how we test elsewhere.
● Let me read the function and a neighbouring test to match your table-driven style.
● Ran sed -n '1,30p' internal/tax/calc.go
└ func Compute(amount int64, rate float64) (int64, error) {
if amount < 0 { return 0, ErrNegativeAmount }
if rate < 0 || rate > 1 { return 0, ErrBadRate }
return int64(float64(amount) * rate), nil
}
● Edited internal/tax/calc_test.go (+9 -0)
● Ran go test ./internal/tax -cover
└ ok internal/tax coverage: 100.0% of statements
● Four cases covering the happy path, a zero, and both error returns. 100% of calc.go covered. Want the same for the sibling rounding helper?
- 01Name the file or module you want covered.
- 02The agent reads the code and your existing tests to learn the conventions.
- 03It writes cases for the happy path, the edges, and the error paths.
- 04It runs the new tests and reports coverage before you commit.
Untested code is the corner of the repo everyone tiptoes around, because changing it means hoping you did not quietly break something you cannot see. Writing the missing tests is worth doing and dull to do, which is why it never makes it off the backlog. It suits Pier well, since the bulk of the job is reading the code closely to work out what it really does, then turning that into cases in whatever testing style you already use.
And it goes past the happy path. The agent reads the function, spots the branches, and writes for the edges that actually bite in production: empty inputs, boundary values, the error path that throws. It copies the shape of your existing tests, reusing the same framework, fixtures, and naming instead of dropping a second style into the suite. Then it runs the new tests, so what you are reviewing is a set that demonstrably passes rather than a hopeful first draft.
Filling in coverage is repetitive and reading-heavy, which makes it both a good fit for an agent and inexpensive to run. There are related jobs in the use cases, and what work like this costs is on the pricing page.
