Go Developer interview question
What is your Go testing strategy?
Go tests should cover behaviour at the smallest useful boundary: table-driven unit tests for pure logic, integration tests for real dependencies, and race detection for concurrent code.
Direct answer
What a strong answer covers
How it works
A Go testing strategy layers cheap, fast tests under a few expensive ones. Table-driven unit tests cover pure logic and edge cases; tests that touch a database or network run against a real dependency in an isolated environment rather than a hand-written mock of SQL; the race detector runs on every package with goroutines. Tests use the public API of a package where possible so refactors do not rewrite the suite, and helpers mark themselves with t.Helper so failures point at the right line.
Example
Run go test -race for packages that share state across goroutines and use t.TempDir or test containers to isolate integration state. A repository package is tested against a throwaway PostgreSQL schema created in TestMain, while the HTTP layer above it is tested with httptest.NewServer and a fake repository that implements the same small interface.
Common mistakes
- Mocking the database driver instead of running the query against a real engine.
- Sharing mutable fixtures between tests so ordering starts to matter.
- Skipping -race locally and discovering data races only in production logs.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.