golang-testing

Workflow

1. Write test function schema: Refer to the definition in reference/schema.yaml, and strictly comply with the schema standard
2. Confirm schema with users: Modify according to user requirements, and start coding only after users are satisfied
3. Minimum implementation: First implement 1 happy path + 1 critical failure case to ensure repeatability.
4. Deliver runnable content: Provide

   go test ...

   command and environment description, users execute manually and return results.
5. Expand test cases: Boundary → Exception → Concurrency/

   -race

   → Regression (must be supplemented when fixing bugs).
6. Finalization: Update Schema (reasons for implemented/unimplemented items) + final operation instructions (including optional parameters).

Best Practice

Principles

• Test behavior, not implementation: Prioritize verification of externally observable behaviors (return values/errors/side effects/external interactions), avoid binding internal details and increasing refactoring costs
• Repeatable, stable, maintainable: Tests should produce consistent results on any machine at any time; failure information can quickly locate problems
• Layered testing: Use unit tests to ensure correct logic and high coverage (fast, stable, isolated dependencies), use integration tests to ensure correct key links (real/near-real dependencies, reduce reliance on mock), use e2e tests to ensure core user paths are available (isolated environment, small and precise, strong observability)
• Isolate external dependencies when mocking: For boundary dependencies such as DB/HTTP/time/random/file system, control the test environment through interfaces and dependency injection

Structure

1. Group by topic/behavior, one Function per group
2. Within each function group, use t.Run subtests to separate different assertion structures
3. Use the same assertion structure within each subtest, and use table-driven to cover more inputs and boundary cases
4. Adopt AAA (Arrange-Act-Assert) or Given-When-Then structure for segmentation to reduce reading cost
5. Avoid "serial if/complex logic" in tests, extract complex preparation processes into helper functions

Techniques

1. For auxiliary functions, mark

   t.Helper()

   , and adopt FailFast strategy for errors
2. Use golden file for complex output judgment, and provide an update switch
3. mock
   1. When mocking an interface, use pure func to implement the interface, which can more conveniently mock different results
   2. When mocking a particularly complex interface, use struct embedding of the interface, and then override the method to be mocked
   3. Verify key interactions when mocking

Must Do

• Add race flag when concurrency is involved
• Cover error paths and critical boundaries
• Tests must be repeatable
• Test failure information must be clear, easy to understand and locate

Don't

• Do not directly test private functions (test through public API)
• Do not use

  time.Sleep()

  in tests: Replace with channel, conditional wait, controllable clock (Clock/now injection).
• Avoid flaky tests