跳到正文
cccskills
免费在 GitHub 公开

golang-stretchr-testify

Write and review Go tests using stretchr/testify. Choose assertions that continue or stop on failure, create mocks that verify expected calls, and organize related tests with shared setup and cleanup routines.

中文简介正在准备中。当前显示英语简介。

原文查看原文说明

Comprehensive guide to stretchr/testify for Golang testing. Covers assert, require, mock, and suite packages in depth. Use when writing tests with testify, creating mocks, setting up test suites, or choosing between assert and require. Covers testify assertions, mock expectations, argument matchers, call verification, suite lifecycle, and advanced patterns like Eventually, JSONEq, and custom matchers. Apply when the codebase imports github.com/stretchr/testify.

实测评分 未实测

查看安装方法

适用场景

  • Choosing between assert and require
  • Creating mocks and verifying expected calls
  • Sharing setup and cleanup across related tests
  • Checking asynchronous results and JSON content

包含的文件(3)

  • SKILL.md7.2 KB
  • evals/evals.json11.9 KB
  • references/mock.md3.1 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

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 — 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), preferred 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)

// Equality
is.Equal(expected, actual)              // DeepEqual + exact type
is.NotEqual(unexpected, actual)
is.EqualValues(expected, actual)        // converts to common type first
is.EqualExportedValues(expected, actual)

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

// Contains (strings, slices, map keys)
is.Contains("hello world", "world")
is.Contains([]int{1, 2, 3}, 2)
is.Contains(map[string]int{"a": 1}, "a")

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

// Errors
is.Error(err)                     is.NoError(err)
is.ErrorIs(err, ErrNotFound)      // walks error chain
is.ErrorAs(err, &target)
is.ErrorContains(err, "not found")

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

Argument order: always (expected, actual) — swapping produces confusing diff output.

Advanced Assertions

is.ElementsMatch([]string{"b", "a", "c"}, result)             // unordered comparison
is.InDelta(3.14, computedPi, 0.01)                            // float tolerance
is.JSONEq(`{"name":"alice"}`, `{"name": "alice"}`)             // ignores whitespace/key order
is.WithinDuration(expected, actual, 5*time.Second)
is.Regexp(`^user-[a-f0-9]+$`, userID)

// Async polling
is.Eventually(func() bool {
    status, _ := client.GetJobStatus(jobID)
    return status == "completed"
}, 5*time.Second, 100*time.Millisecond)

// Async polling with rich assertions
is.EventuallyWithT(func(c *assert.CollectT) {
    resp, err := client.GetOrder(orderID)
    assert.NoError(c, err)
    assert.Equal(c, "shipped", resp.Status)
}, 10*time.Second, 500*time.Millisecond)

testify/mock

Mock interfaces to isolate the unit under test. Embed mock.Mock, implement methods with m.Called(), always verify with AssertExpectations(t).

Key matchers: mock.Anything, mock.AnythingOfType("T"), mock.MatchedBy(func). Call modifiers: .Once(), .Times(n), .Maybe(), .Run(func).

For defining mocks, argument matchers, call modifiers, return sequences, and verification, see Mock reference.

testify/suite

Suites group related tests with shared setup/teardown.

Lifecycle

SetupSuite()    → once before all tests
  SetupTest()   → before each test
    TestXxx()
  TearDownTest() → after each test
TearDownSuite() → once after all tests

Example

type TokenServiceSuite struct {
    suite.Suite
    store   *MockTokenStore
    service *TokenService
}

func (s *TokenServiceSuite) SetupTest() {
    s.store = new(MockTokenStore)
    s.service = NewTokenService(s.store)
}

func (s *TokenServiceSuite) TestGenerate_ReturnsValidToken() {
    s.store.On("Save", mock.Anything, mock.Anything).Return(nil)
    token, err := s.service.Generate("user-42")
    s.NoError(err)
    s.NotEmpty(token)
    s.store.AssertExpectations(s.T())
}

// Required launcher
func TestTokenServiceSuite(t *testing.T) {
    suite.Run(t, new(TokenServiceSuite))
}

Suite methods like s.Equal() behave like assert. For require: s.Require().NotNil(obj).

Common Mistakes

  • Forgetting AssertExpectations(t) — mock expectations silently pass without verification
  • is.Equal(ErrNotFound, err) — fails on wrapped errors. Use is.ErrorIs to walk the chain
  • Swapped argument order — testify assumes (expected, actual). Swapping produces backwards diffs
  • assert for guards — test continues after failure and panics on nil dereference. Use require
  • Missing suite.Run() — without the launcher function, zero tests execute silently
  • Comparing pointers — is.Equal(ptr1, ptr2) compares addresses. Dereference or use EqualExportedValues

Linters

Use testifylint to catch wrong argument order, assert/require misuse, and more. See samber/cc-skills-golang@golang-lint skill.

Cross-References

  • → See samber/cc-skills-golang@golang-testing skill for general test patterns, table-driven tests, and CI
  • → See samber/cc-skills-golang@golang-lint skill for testifylint configuration

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Measure Go performance by writing benchmarks, examining CPU and memory profiles, and comparing repeated runs with benchstat. Use the results to assess code changes, detect slowdowns in CI, and investigate production performance.

中文简介正在准备中。当前显示英语简介。

  • Compare performance before and after a code change
  • Investigate CPU usage and memory allocations
  • Detect performance regressions in CI
samber/cc-skills-golang36022026年10月23日 更新

Build, extend, or review Go command-line tools with clear commands, flags, and configuration priorities. It guides output formats, exit codes, shell completion, cancellation, and tests so tools behave predictably in scripts and terminals.

中文简介正在准备中。当前显示英语简介。

  • Build a Go command-line tool with subcommands
  • Combine flags, environment variables, and configuration files
  • Review output and exit codes for use in scripts
samber/cc-skills-golang36022026年10月23日 更新

Make Go code easier to read by reviewing line breaks, variable declarations, branching, function parameters, and file organization. Provides concrete style guidance for implementation, code reviews, and project standards where formatting tools alone cannot judge clarity.

中文简介正在准备中。当前显示英语简介。

  • Reviewing Go code for readability
  • Simplifying nested branches and complex conditions
  • Improving long function signatures and calls
samber/cc-skills-golang36022026年10月23日 更新

Design and review concurrent Go code with clear goroutine ownership, shutdown paths, and error handling. Choose channels, locks, or atomic operations to protect shared data, and structure worker pools with controlled concurrency and cancellation.

中文简介正在准备中。当前显示英语简介。

  • Design goroutine shutdown and cancellation
  • Choose channels or mutexes for concurrent code
  • Protect shared maps and counters
samber/cc-skills-golang36022026年10月23日 更新

Design how Go requests carry cancellation signals, time limits, and request metadata through application layers. Helps investigate work that continues after cancellation, choose suitable context types, and separate background tasks from the request lifecycle.

中文简介正在准备中。当前显示英语简介。

  • Reviewing context propagation from HTTP handlers to database calls
  • Investigating missing cancellation and lingering timers
  • Keeping background work running after a request ends
samber/cc-skills-golang36022026年10月23日 更新

Set up or improve GitHub Actions pipelines for Go projects. Configure automated tests, code checks, vulnerability scans, dependency update bots, releases, and Docker publishing, with workflow templates and repository settings that control permissions and merge requirements.

中文简介正在准备中。当前显示英语简介。

  • Set up automated tests and code checks for Go
  • Add vulnerability scanning to a pipeline
  • Configure dependency update bots
samber/cc-skills-golang36022026年10月23日 更新

查看 samber 的全部技能

报告此技能的问题