go-unit-tests

Writes and fixes Go unit tests using table-driven tests with testify and testify/mock.

2|Updated Sep 2, 2022
One-click install
npx skills add https://github.com/silvioubaldino/personal-finance --skill go-unit-tests-silvioubaldino
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: go-unit-tests
Source: https://github.com/silvioubaldino/personal-finance/tree/main/.claude/skills/go-unit-tests
Command: npx skills add https://github.com/silvioubaldino/personal-finance --skill go-unit-tests-silvioubaldino

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing consistent Go unit tests is hard when teams mix styles, use conditional assertions, or misuse mocks. This Skill enforces a single authoritative convention for Go unit tests so every test file follows the same table-driven, testify-based structure. ## Core Features & Use Cases - Table-Driven Test Generation: Produces one map-keyed table test per function with descriptive should ... when ... case names and predeclared input/expected types. - Strict Mocking Conventions: Enforces testify/mock usage with real argument matching (no mock.Anything), ctx-free m.Called calls, mock reuse checks, and deferred AssertExpectations. - Uniform Assertions Without Branching: Requires assert.ErrorIs for all error checks including success cases, eliminating if/switch statements in test bodies. - Use Case: When adding coverage for a new usecase or repository method, ask for tests and receive a compliant test file plus a mock_test.go template that passes go test on the first run. ## Quick Start Write unit tests for the GetByID method in internal/usecase following the repo's Go testing conventions.

Frequently Asked Questions about go-unit-tests

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write table-driven unit tests in Go?▼

Define a map[string]struct keyed by descriptive test names like "should return error when repository fails", with input, mockSetup, and expected fields. Loop over the map with t.Run and follow a single Arrange/Act/Assert path for every case.

How to use testify/mock for Go repository mocking?▼

Define a Mock struct embedding mock.Mock in mock_test.go, create instances with the address-of operator, and set expectations with On using real argument values. Defer AssertExpectations right after construction and ignore ctx inside m.Called.

Should I use assert.NoError or assert.ErrorIs in Go tests?▼

Use assert.ErrorIs(t, err, tc.expected.err) for every case including success, since errors.Is(nil, nil) is true. This keeps one uniform assertion per test and eliminates conditional branches in test bodies.

Why avoid mock.Anything in testify mock expectations?▼

mock.Anything hides argument mismatches that indicate real bugs. Matching on concrete expected values, such as a fixture UUID, makes tests verify actual call behavior and fail when the code passes wrong arguments.

When should I not use this Go testing style?▼

This style targets unit tests with mocked dependencies; it is not designed for integration tests, benchmarks, or fuzz tests. Cases needing genuinely different control flow may require separate test functions rather than one table.