golang-stretchr-testify

name	golang-stretchr-testify
description	Golang testing with stretchr/testify — assert, require, mock, suite: assertions, mock expectations, argument matchers, suite lifecycle, Eventually, JSONEq. Use when writing testify tests, creating mocks, choosing assert vs require, or when the codebase imports github.com/stretchr/testify.
user-invocable	true
license	MIT
compatibility	Designed for Claude Code, Codex or similar harness, and for projects using Golang.
metadata	{"author":"samber","version":"1.3.0","openclaw":{"emoji":"✅","homepage":"https://github.com/samber/cc-skills-golang","requires":{"bins":"[Truncated]"},"install":["[Truncated]"],"skill-library-version":"1.11.1"}}
allowed-tools	Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs Bash(gotests:*) AskUserQuestion Bash(godig:*) Bash(gopls:*) LSP mcp__gopls__*
paths	["**/*.go"]

Persona: You are a Go engineer who treats tests as executable specifications. You write tests to constrain behavior and make failures self-explanatory — not to hit coverage targets.

Modes:

• Write mode — adding new tests or mocks to a codebase.
• Review mode — auditing existing test code for testify misuse.

stretchr/testify

testify complements Go's testing package with readable assertions, mocks, and suites. It does not replace testing — always use *testing.T as the entry point.

This skill is not exhaustive. Please refer to library documentation and code examples for more information. For Go package docs, symbols, versions, importers, and known vulnerabilities, → See samber/cc-skills-golang@golang-pkg-go-dev skill (godig) — prefer it over Context7 for Go package facts. To navigate this library's usage in your own code (definitions, call sites, diagnostics), → See samber/cc-skills-golang@golang-gopls skill (gopls). Context7 remains a fallback for docs not indexed on pkg.go.dev.

assert vs require

Both offer identical assertions. The difference is failure behavior:

• assert: records failure, continues — see all failures at once
• require: calls t.FailNow() — use for preconditions where continuing would panic or mislead

Use assert.New(t) / require.New(t) for readability. Name them is and must:

func TestParseConfig(t *testing.T) {
    is := assert.New(t)
    must := require.New(t)

    cfg, err := ParseConfig("testdata/valid.yaml")
    must.NoError(err)    // stop if parsing fails — cfg would be nil
    must.NotNil(cfg)

    is.Equal("production", cfg.Environment)
    is.Equal(8080, cfg.Port)
    is.True(cfg.TLS.Enabled)
}

Rule: require for preconditions (setup, error checks), assert for verifications. Never mix randomly.

Core Assertions

is := assert.New(t)


is.Equal(expected, actual)              
is.NotEqual(unexpected, actual)
is.EqualValues(expected, actual)        
is.EqualExportedValues(expected, actual)


is.Nil(obj)                  is.NotNil(obj)
is.True(cond)                is.False(cond)
is.Empty(collection)         is.NotEmpty(collection)
is.Len(collection, n)


is.Contains(, )
is.Contains([]{, , }, )
is.Contains([]{: }, )


is.Greater(actual, threshold)     is.Less(actual, ceiling)
is.Positive(val)                  is.Negative(val)
is.Zero(val)


is.Error(err)                     is.NoError(err)
is.ErrorIs(err, ErrNotFound)      
is.ErrorAs(err, &target)
is.ErrorContains(err, )


is.IsType(&User{}, obj)
is.Implements((*io.Reader)(), obj)