testing: add more unit tests to increase branch coverage

[mohammed90]

Self-expalantory. We need to add more tests; and I wondered if LLMs could generate tests covering all the logic branches, so this is the result.

Assistance Disclosure

I used Amp to generate the tests, tweaked few by hand, and fixed the bug by hand. The generated code will not be taken and accepted at face value. Changes to the source code (not tests) by the agent will not be accepted. Only the tests cases with study of coverage.

Prompt:

Study the full codebase of the project. Write unit tests to validate the functionality and ensure robustness. The tests should check for the intended behavior, not the behavior as written. It is possible the existing code base has an unknown defect, for which we need the unit tests to uncover. Write the unit tests.

[mohammed90]

Total change in coverage:

=== BEFORE (master) ===
total: (statements) 47.4%
=== AFTER (add-tests) ===
total: (statements) 49.3%

Per file delta:

File	Before	After	Delta
configadapters.go	0.0%	100%	+100 pp
logbuffer.go	0.0%	100%	+100 pp
logs.go	0.0%	100%	+100 pp
policy.go	0.0%	100%	+100 pp
values.go	0.0%	100%	+100 pp
marshalers.go	0.0%	88.9%	+88.9 pp
storage.go	0.0%	83.3%	+83.3 pp
listeners.go	0.0%	82.4%	+82.4 pp
errors.go	36.4%	100%	+63.6 pp
importargs.go	85.7%	100%	+14.3 pp
logmarshalers.go	87.5%	100%	+12.5 pp
frontmatter.go	87.5%	100%	+12.5 pp
serveroptions.go	63.9%	72.1%	+8.2 pp
link.go	94.7%	100%	+5.3 pp

[mohammed90]

File	Before	After	Δ
admin.go	64.8%	73.7%	+8.9pp
logappend.go	50.0%	75.0%	+25.0pp
intercept.go	47.5%	60.9%	+13.4pp
Workspace total	49.3%	49.4%	+0.1pp

[mholt]

Thanks for working on this Mohammed! Can't wait to review this when it's ready.

Random side note: I wonder if we should turn off verbose output for our tests, and only show failures, it's a LOT to scroll through otherwise.

[francislavoie]

Random side note: I wonder if we should turn off verbose output for our tests, and only show failures, it's a LOT to scroll through otherwise.

I think that's probably a good idea. We rarely need to analyze the specific details of the output, it ends up just being a lot of noise. We can run it locally with more verbosity, or just commit a flag while dev-ing on a PR to make it louder when debugging.

---

It makes me sad that Go's module system causes the top-level dir of the project to get so polluted with files, especially test files which aren't particularly meaningful to be located there. Is there really nothing we can do about this? 😭 It's a lot of new files.

I'm not sure I'll ever really have time to dive deep on these tests, but since it's almost entirely just tests that are passing, I see no harm in merging this if you're happy with it @mohammed90