{"id":213,"date":"2026-05-10T13:04:15","date_gmt":"2026-05-10T13:04:15","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/go-testify-2026-what-i-actually-use\/"},"modified":"2026-05-10T13:04:15","modified_gmt":"2026-05-10T13:04:15","slug":"go-testify-2026-what-i-actually-use","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/go-testify-2026-what-i-actually-use\/","title":{"rendered":"Go testify in 2026: What I Actually Use (and What I Dropped)"},"content":{"rendered":"

Confession: I spent four years writing Go tests with testify before I sat down and asked whether I actually needed it. The answer turned out to be “for some things, yes; for most things, the standard library is fine, and I was just used to typing assert.Equal<\/code>.” This post is what I figured out, with code, after migrating one large service away from testify (mostly) and a smaller one onto it.<\/p>\n

If you’re new to Go and the only test framework you’ve heard of is testify<\/a>, this post will save you some reading. If you’ve been using it for years, this post is the conversation I wish my older coworkers had with me when I started.<\/p>\n

Short answer: I still use assert<\/code> and require<\/code> for value comparisons in a few places. I don’t use mock<\/code> anymore, and I gave up on suite<\/code>. The real win in 2026 is that the standard testing<\/code> package<\/a> plus a couple of small libraries cover 95% of what I used to reach for testify for.<\/p>\n

What testify actually gives you<\/h2>\n

Testify is three packages bundled together: assert<\/code>, require<\/code>, mock<\/code>, plus the suite<\/code> runner. Each one solves a different real problem.<\/p>\n

assert<\/code> and require<\/code> give you readable expectation helpers. Instead of writing if got != want { t.Errorf(\"got %v, want %v\", got, want) }<\/code>, you write assert.Equal(t, want, got)<\/code>. The output on failure includes both values and a diff for structs.<\/p>\n

mock<\/code> gives you a runtime mock object generator. You declare expected calls, run your code, and assert at the end that the mock was called as expected.<\/p>\n

suite<\/code> gives you a test class with SetupTest<\/code>, TearDownTest<\/code>, and shared state, like xUnit-style frameworks in other languages.<\/p>\n

These are real conveniences. They’re also opinions about how testing should work, and the opinions don’t always age well in Go specifically.<\/p>\n

assert vs require: the only rule I still follow<\/h2>\n

If you take one thing from this post: assert<\/code> lets the test keep running after a failure, require<\/code> stops it. That distinction matters more than people give it credit for.<\/p>\n

Here’s a test where I want to check several independent things on a response:<\/p>\n

func TestUserResponse(t *testing.T) {\n    resp := getUser(t, 42)\n\n    assert.Equal(t, 42, resp.ID)\n    assert.Equal(t, "Qasim", resp.Name)\n    assert.NotEmpty(t, resp.Email)\n    assert.False(t, resp.Deleted)\n}\n<\/code><\/pre>\n
If resp.Name<\/code> is wrong, I still want to know whether resp.Email<\/code> is also wrong. Four assert<\/code> calls, four independent checks, one test run.<\/p>\n
But here’s a test where the second check is meaningless if the first one fails:<\/p>\n
func TestParseConfig(t *testing.T) {\n    cfg, err := config.Parse("config.yaml")\n    require.NoError(t, err)        \/\/ if this fails, cfg is nil\n    require.NotNil(t, cfg)         \/\/ sanity check before dereferencing\n\n    assert.Equal(t, "production", cfg.Env)\n    assert.Equal(t, 5432, cfg.DBPort)\n}\n<\/code><\/pre>\n
If Parse<\/code> errored, cfg<\/code> is nil, and dereferencing it in the next assertion would panic. require.NoError<\/code> halts the test before that happens.<\/p>\n
The rule I live by: use require<\/code> for preconditions (parsing succeeded, the response was non-nil, the database returned something) and assert<\/code> for the actual things you’re testing. If you find yourself writing require.Equal<\/code> for the thing under test, you probably want assert<\/code> so you see all failures, not just the first one.<\/p>\n
Where I stopped using mock<\/h2>\n
I used testify\/mock<\/code> for years. I don’t anymore, and the reason is that Go’s interface system makes it unnecessary.<\/p>\n
Here’s what testify mocks look like:<\/p>\n
type MockEmailer struct {\n    mock.Mock\n}\n\nfunc (m *MockEmailer) Send(to, subject, body string) error {\n    args := m.Called(to, subject, body)\n    return args.Error(0)\n}\n\nfunc TestSignup(t *testing.T) {\n    m := new(MockEmailer)\n    m.On("Send", "user@example.com", "Welcome", mock.Anything).Return(nil)\n\n    svc := signup.New(m)\n    err := svc.Register("user@example.com")\n\n    require.NoError(t, err)\n    m.AssertExpectations(t)\n}\n<\/code><\/pre>\n
That works. It’s also a lot of ceremony for what’s essentially “did the function call Send with the right arguments.” Here’s the version I write now, with no testify:<\/p>\n
type fakeEmailer struct {\n    sent []sentEmail\n}\n\ntype sentEmail struct{ to, subject, body string }\n\nfunc (f *fakeEmailer) Send(to, subject, body string) error {\n    f.sent = append(f.sent, sentEmail{to, subject, body})\n    return nil\n}\n\nfunc TestSignup(t *testing.T) {\n    f := &fakeEmailer{}\n    svc := signup.New(f)\n\n    err := svc.Register("user@example.com")\n    if err != nil {\n        t.Fatal(err)\n    }\n\n    if len(f.sent) != 1 {\n        t.Fatalf("want 1 email, got %d", len(f.sent))\n    }\n    if f.sent[0].to != "user@example.com" {\n        t.Errorf("wrong recipient: %q", f.sent[0].to)\n    }\n}\n<\/code><\/pre>\n
More lines? Yes, by about six. But:<\/p>\n
I can see exactly what was sent and assert on it normally. There’s no string-based method matching. Refactoring the Emailer<\/code> interface (renaming Send<\/code>, changing the signature) immediately fails to compile, instead of silently passing a test that mocked the old name.<\/p>\n
I don’t have a MockSomething<\/code> parallel hierarchy that I have to keep in sync with my real interface. The fake is just another implementation.<\/p>\n
The mock library does have one thing fakes don’t: built-in argument matching like mock.Anything<\/code>, mock.AnythingOfType(\"string\")<\/code>. I’ve found that when I need that, my test is doing too much. The fix is usually to make my interface narrower, not to match against Anything<\/code>.<\/p>\n
suite: I gave up on this one<\/h2>\n
suite.Suite<\/code> lets you define SetupTest<\/code> and TearDownTest<\/code> methods on a struct, with shared state, like JUnit. I used it for database integration tests for a year. Then I switched to plain test helpers and was happier.<\/p>\n
The problem with suite.Run<\/code> is that it hides what’s happening. New people on the team had to learn the suite lifecycle (which methods get called when, in what order, what SetupTest<\/code> vs SetupSuite<\/code> does) instead of just reading the test top to bottom. I had bugs where state leaked between subtests because I’d written SetupSuite<\/code> instead of SetupTest<\/code> and didn’t notice.<\/p>\n
The plain Go version uses t.Cleanup<\/code> and a helper:<\/p>\n
func setupDB(t *testing.T) *sql.DB {\n    t.Helper()\n    db := openTestDB(t)\n    t.Cleanup(func() {\n        db.Exec("TRUNCATE users CASCADE")\n        db.Close()\n    })\n    return db\n}\n\nfunc TestCreateUser(t *testing.T) {\n    db := setupDB(t)\n    err := users.Create(db, "qasim@example.com")\n    if err != nil {\n        t.Fatal(err)\n    }\n}\n<\/code><\/pre>\n
Each test sets up its own state. t.Cleanup<\/code> runs in reverse order when the test ends, even if it failed or panicked. There’s no shared receiver. If two tests need the same setup, I extract a helper. If they need different setup, they don’t share one.<\/p>\n
This isn’t an indictment of suite. If you’ve used JUnit-style frameworks for years and the suite mental model is comfortable, fine. But the plain-Go version is right there, and it doesn’t require remembering which lifecycle hook runs when.<\/p>\n
What I actually reach for in 2026<\/h2>\n
For value comparisons that aren’t deeply nested, plain t.Errorf<\/code> with a clear message. The diff is rarely worth the dependency.<\/p>\n
For deeply nested struct comparisons, google\/go-cmp<\/a>. It’s by far the best diff output in Go and it has good options for ignoring unexported fields, comparing floats with tolerance, and so on:<\/p>\n
if diff := cmp.Diff(want, got); diff != "" {\n    t.Errorf("response mismatch (-want +got):\\n%s", diff)\n}\n<\/code><\/pre>\n
For HTTP handlers, httptest.NewRecorder<\/code> and reading rec.Code<\/code>, rec.Body.String()<\/code>. Faster than building a request mock, and exactly the API the standard library gives you.<\/p>\n
For database integration tests, plain helpers and t.Cleanup<\/code>, plus testing.Short()<\/code> to skip them on CI fast-runs.<\/p>\n
For cases where I’d otherwise reach for assert.Equal<\/code> heavily across a single repo, I still pull in testify. The four lines vs one line trade-off matters when you have hundreds of assertions. I just don’t use mock<\/code> or suite<\/code> from it. Some thoughts on this kind of decision live in my Go error handling patterns<\/a> post, since “what to do when something fails” applies to test code too.<\/p>\n
Migrating off testify (or onto it)<\/h2>\n
If you’re considering moving off testify, don’t do it all at once. The pattern that worked for me:<\/p>\n
Step one, stop adding new tests with mock<\/code> and suite<\/code>. Use fakes and helpers in any new code.<\/p>\n
Step two, when you touch an old test that uses mocks, replace it with a fake. Don’t migrate just for the sake of migrating, but when you’re already in there, take the ten minutes.<\/p>\n
Step three, leave assert<\/code> and require<\/code> in place. They’re fine. Removing them for ideological reasons just makes diffs noisier without making the code better.<\/p>\n
If you’re considering moving onto testify, the decision is smaller than it feels. Add it. Use require<\/code> for preconditions and assert<\/code> for checks. Skip mock<\/code> and suite<\/code> until you have a specific reason to use them. If you never have that reason, you’ve spent zero time learning APIs you don’t use.<\/p>\n
What to try this week<\/h2>\n
Pick one test file in your project that uses mocks heavily. Convert one mock to a fake (a struct that implements the same interface, with a slice that records calls). Run the test. See if you find the new version easier to understand. If yes, keep going. If no, the mock library is doing something for you, and you should figure out what.<\/p>\n
If you don’t use testify yet, try this: write your next test with require.NoError<\/code> for the precondition checks and assert.Equal<\/code> for the actual checks. See if the failure messages are more useful than what you had before. If they are, you’ve justified the dependency. If they aren’t, the standard library was already doing fine.<\/p>\n
You can see a few of the Go services I’ve shipped on my portfolio<\/a>, and they’re a mix: some use testify, some don’t. I stopped picking sides about this years ago. Picking the right testing tool for a specific test matters a lot more than picking the right framework for the whole repo.<\/p>\n","protected":false},"excerpt":{"rendered":"
Four years with testify, then I migrated off it. What I kept (assert and require), what I dropped (mock and suite), and the plain-Go alternatives I prefer.<\/p>\n","protected":false},"author":2,"featured_media":212,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"Four years with testify, then I migrated off it. What I kept (assert and require), what I dropped (mock and suite), and the plain-Go alternatives I prefer.","rank_math_focus_keyword":"go testify","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[147],"tags":[46,47,253,30,201],"class_list":["post-213","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-backend","tag-go","tag-golang","tag-testify","tag-testing","tag-tooling"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=213"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/213\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/212"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}