🤖 Generated by the Daily AI Assistant
Part of the go-template roadmap #67.
Problem
The scaffold ships no tests at all (go.sum is empty, there are zero *_test.go files) and main.go is a no‑op (os.Exit(0)). Two consequences:
- The org‑required
validate-go-project workflow runs 🧪 Test and 📊 Code Coverage on every PR, but there is nothing to exercise — the jobs pass vacuously and the template never demonstrates that its own test/coverage tooling works.
- A new project created from the template inherits no testing pattern — no example of the house layout, table‑driven style, or how a test sits next to the code it covers.
The sibling dotnet-template already ships a minimal example for exactly this purpose: src/Example/ExampleClass.cs + tests/Example.Tests/ExampleClassTests.cs (a placeholder class and a single trivial test). go-template should have the Go equivalent — this is the clearest template‑parity gap (roadmap #67, parity lens).
Proposed direction
Add a tiny, idiomatic example package under the conventional layout (the pkg/ / internal/ dirs already exist as .gitkeep placeholders), plus its test:
- e.g.
pkg/example/example.go — a single small exported function with a doc comment (mirroring the spirit of dotnet's empty ExampleClass, but with one trivial function so there's behaviour to assert).
pkg/example/example_test.go — one idiomatic (ideally table‑driven) test asserting that behaviour.
Keep it minimal and deletable — a clear "replace me" example, not product code. Add a one‑liner to the README pointing newcomers at it as the starting pattern. Decide whether to keep main.go as the entry point or have the example demonstrate library‑style layout (the repo carries both main.go and pkg/).
Acceptance criteria
Size
S — a few lines of example code + one test + a README line.
Part of the go-template roadmap #67.
Problem
The scaffold ships no tests at all (
go.sumis empty, there are zero*_test.gofiles) andmain.gois a no‑op (os.Exit(0)). Two consequences:validate-go-projectworkflow runs🧪 Testand📊 Code Coverageon every PR, but there is nothing to exercise — the jobs pass vacuously and the template never demonstrates that its own test/coverage tooling works.The sibling dotnet-template already ships a minimal example for exactly this purpose:
src/Example/ExampleClass.cs+tests/Example.Tests/ExampleClassTests.cs(a placeholder class and a single trivial test). go-template should have the Go equivalent — this is the clearest template‑parity gap (roadmap #67, parity lens).Proposed direction
Add a tiny, idiomatic example package under the conventional layout (the
pkg//internal/dirs already exist as.gitkeepplaceholders), plus its test:pkg/example/example.go— a single small exported function with a doc comment (mirroring the spirit of dotnet's emptyExampleClass, but with one trivial function so there's behaviour to assert).pkg/example/example_test.go— one idiomatic (ideally table‑driven) test asserting that behaviour.Keep it minimal and deletable — a clear "replace me" example, not product code. Add a one‑liner to the README pointing newcomers at it as the starting pattern. Decide whether to keep
main.goas the entry point or have the example demonstrate library‑style layout (the repo carries bothmain.goandpkg/).Acceptance criteria
go test ./...runs at least one real, passing test (non‑vacuous assertion).go.sumreflects any test deps actually used (prefer stdlibtestingonly — no new deps unless justified).golangci-lint runand the mega‑linter stay green on the new files.Size
S — a few lines of example code + one test + a README line.