HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
stretchr
testify
Go2016–2025
stretchr / testify

testify

A toolkit with common assertions and mocks that plays nicely with the standard library

23Distinct people
25Mentions
3Explicit recommenders
26.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A toolkit with common assertions and mocks that plays nicely with the standard library

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

This article is too basic and does not introduce anything you'd encounter in a typical Go project. If you want introduction to Go testing I recommend just reading the official…

karolist used a recommendation phrase. 4 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year25 dated mentions

Observed mentions: 2016-05-01 20:19:30 UTC to 2025-08-06 14:12:55 UTC.

0123452016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC303
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC404
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC505
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC110
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC312
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC211

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Testify - Thou Shalt Write Tests NoteTestify is being maintained at v1, no breaking changes will be accepted in this repo. See discussion about v2. Go code (golang) set of packages that provide many tools for testifying that your code will behave as you intend. Features include: Easy assertions Mocking Testing suite interfaces and functions Get started: Install testify with one line of code, or update it with another For an introduction to writing test code in Go, see https://go.dev/doc/code#Testing Check out the API Documentation https://pkg.go.dev/github.com/stretchr/testify Use testifylint (via golangci-lint) to avoid common mistakes A little about Test-Driven Development (TDD) assert package The assert package provides some helpful methods that allow you to write better test code in Go. Prints friendly, easy to read failure descriptions Allows for very readable code Optionally annotate each assertion with a message See it in action: package yours import ( "testing" "github.com/stretchr/testify/assert" ) func TestSomething(t *testing.T) { // assert equality assert.Equal(t, 123, 123, "they should be equal") // assert inequality assert.NotEqual(t, 123, 456, "they should not be equal") // assert for nil (good for errors) assert.Nil(t, object) // assert for not nil (good when you expect something) if assert.NotNil(t, object) { // now we know that object isn't nil, we are safe to make // further assertions without causing any errors assert.Equal(t, "Something", object.Value) } } Every assert func takes the testing.T object as the first argument. This is how it writes the errors out through the normal go test capabilities. Every assert func returns a bool indicating whether the assertion was successful or not, this is useful for if you want to go on making further assertions under certain conditions. if you assert many times, use the below: package yours import ( "testing" "github.com/stretchr/testify/assert" ) func TestSomething(t *testing.T) { assert := assert.New(t) // assert equality assert.Equal(123, 123, "they should be equal") // assert inequality assert.NotEqual(123, 456, "they should not be equal") // assert for nil (good for errors) assert.Nil(object) // assert for not nil (good when you expect something) if assert.NotNil(object) { // now we know that object isn't nil, we are safe to make // further assertions without causing any errors assert.Equal("Something", object.Value) } } require package The require package provides same global functions as the assert package, but instead of returning a boolean result they terminate current test. These functions must be called from the goroutine running the test or benchmark function, not from other goroutines created during the test. Otherwise race conditions may occur. See t.FailNow for details. mock package The mock package provides a mechanism for easily writing mock objects that can be used in place of real objects when writing test code. An example test function that tests a piece of code that relies on an external object testObj, can set up expectations (testify) and assert that they indeed happened: package yours import ( "testing" "github.com/stretchr/testify/mock" ) /* Test objects */ // MyMockedObject is a mocked object that implements an interface // that describes an object that the code I am testing relies on. type MyMockedObject struct { mock.Mock } // DoSomething is a method on MyMockedObject that implements some interface // and just records the activity, and returns what the Mock object tells it to. // // In the real object, this method would do something useful, but since this // is a mocked object - we're just going to stub it out. // // NOTE: This method is not being tested here, code that uses this object is. func (m *MyMockedObject) DoSomething(number int) (bool, error) { args := m.Called(number) return args.Bool(0), args.Error(1) } /* Actual test functions */ // TestSomething is an example of how to use our test object to // make assertions about some target code we are testing. func TestSomething(t *testing.T) { // create an instance of our test object testObj := new(MyMockedObject) // set up expectations testObj.On("DoSomething", 123).Return(true, nil) // call the code we are testing targetFuncThatDoesSomethingWithObj(testObj) // assert that the expectations were met testObj.AssertExpectations(t) } // TestSomethingWithPlaceholder is a second example of how to use our test object to // make assertions about some target code we are testing. // This time using a placeholder. Placeholders might be used when the // data being passed in is normally dynamically generated and cannot be // predicted beforehand (eg. containing hashes that are time sensitive) func TestSomethingWithPlaceholder(t *testing.T) { // create an instance of our test object testObj := new(MyMockedObject) // set up expectations with a placeholder in the argument list testObj.On("DoSomething", mock.Anything).Return(true, nil) // call the code we are testing targetFuncThatDoesSomethingWithObj(testObj) // assert that the expectations were met testObj.AssertExpectations(t) } // TestSomethingElse2 is a third example that shows how you can use // the Unset method to cleanup handlers and then add new ones. func TestSomethingElse2(t *testing.T) { // create an instance of our test object testObj := new(MyMockedObject) // set up expectations with a placeholder in the argument list mockCall := testObj.On("DoSomething", mock.Anything).Return(true, nil) // call the code we are testing targetFuncThatDoesSomethingWithObj(testObj) // assert that the expectations were met testObj.AssertExpectations(t) // remove the handler now so we can add another one that takes precedence mockCall.Unset() // return false now instead of true testObj.On("DoSomething", mock.Anything).Return(false, nil) testObj.AssertExpectations(t) } For more information on how to wr
Read the full README on GitHub

What Hacker News says

25 sources
razzie·Jan 1, 2025Submission

Show HN: Testify mock without the boilerplate (Golang)

I've been annoyed by writing boilerplate code for testify mocks, so I made this super lightweight and modest library that can generate mocks for any interface during runtime, without extra build steps. There is a readme file in the repo root with a code snippet that hopefully explains the intended usage. For those unfamiliar with testify mock: https://pkg.go.dev/github.com/stretchr/testify/mock
1 points · Open discussion
karolist·Aug 3, 2024Recommendation phrase
This article is too basic and does not introduce anything you'd encounter in a typical Go project. If you want introduction to Go testing I recommend just reading the official docs https://pkg.go.dev/testing and understanding how to write table driven tests - https://go.dev/wiki/TableDrivenTests. Going beyond what's built in, get familiar with https://github.com/stretchr/testify as that's used a lot.
In Full Introduction to Golang with Test-Driven Development

Show HN: Testy, a better Golang testing library

Hi HN, I'd like to show you Testy [0], a small testing library for golang that I've just released today. Golang is interesting because it has an extremely powerful builtin testing framework, `testing`, that supports both soft and hard checks/assertions. Soft checks mark the test as failed but allow it to continue running. Hard checks mark the test as failed and immediately cause it to end, like asserts traditionally do in most languages. There are a few established testing libraries (testify [1], gotest.tools [2], and is [3]) that take advantage of this in various ways, but they each have drawbacks. - testify supports both hard and soft style checks. They call the soft checks "asserts", and the hard checks "requires", to the confusion of all. Their API has a massive surface area, which is confusing for developers trying to write tests. It
Read the rest
uses `reflect.DeepEquals` for deep equality, which is painful for common operations like comparing `time.Time` structs. And their API isn't typesafe, so refactoring existing tests is a pain. - gotest.tools has a smaller API surface area, and does some cool tricks with AST parsing in order to show meaningful failure messages. It uses `go-cmp` for deep equality, which is the right choice. But the API is confusing, the not typesafe, and it doesn't have soft style checks for everything. - is has a too-small API surface area, to the point that it's missing NotEquals checks. It is also built around `reflect.DeepEquals`, and is not typesafe. Testy, my new library, addresses all of these issues. It's typesafe, using generics. It uses `go-cmp` for deep equality testing. It has soft checks and hard asserts. It has a small, but sufficient, API surface area that makes it easy to learn and use. And it comes with structural helpers for giving your tests clearer meaning and failure output, making your tests more useful. Give it a shot and let me know what you think! My one big question is whether or not to expand the surface area of the API and add more helpers, for things like comparing lengths, checking whether or not an object is in a slice or map, etc. Comments and feedback appreciated greatly! [0] https://github.com/peterldowns/testy [1] https://github.com/stretchr/testify [2] https://github.com/gotestyourself/gotest.tools [3] https://github.com/matryer/is
2 points · Open discussion
Things I can't live without in a new Go project in no particular order: - https://github.com/golangci/golangci-lint - meta-linter - https://goreleaser.com - automate release workflows - https://magefile.org - build tool that can version your tools - https://godoc.org/github.com/ory/dockertest/v3 - run containers for e2e testing - https://github.com/ecordell/optgen - generate functional options - https://golang.org/x/tools/cmd/stringer - generate String() - https://mvdan.cc/gofumpt - stricter gofmt - https://github.com/stretchr/testify - test assertion library - https://github.com/rs/zerolog - logging - https://github.com/spf13/cobra - CLI framework FWIW, I just lifted all the tools we use for https://github.com/authzed/spicedb We've also written some custom linters that might be useful for other folks: https://github.com/authzed/spicedb/t
Read the rest
In How to start a Go project in 2023
Not really a framework, but I really like how golang made testing part of the language/stdlib/tooling. Is it perfect? No. Is it pretty good? Yeah. In terms of frameworks, I am a big fan of testify. [0] Unfortunately it doesn't seem like the testify maintainers want to incorporate generics. [1] I'm going to be releasing a library soon to address that. I'm also going to be releasing a golang+python+typescript library for doing super cheap/fast database-backed tests. In my last job I found it incredibly useful, it essentially made it ~0 cost to write tests that exercised database-related codepaths and logic, which for most business apps is everything important. [0] https://github.com/stretchr/testify [1] https://github.com/stretchr/testify/issues/1147
In Ask HN: What's your favorite software testing framework and why?
In inheritance OOP languages, interfaces are an implementation detail of the class. In Golang, they are proxies. You have to think about them differently. Also I agree with the other commenter that all this verbosity isn't very idiomatic. If you can't just write if a != expected { t.Failf(...) } for each thing, then use testify, because they definitely have been thinking about this long enough to get it right: github.com/stretchr/testify
In Down the Golang Nil Rabbit Hole
Well, in this particular case it was hard. The used version of one our internal libraries didn't support Go 1.13, so we bumped its version, and that required some more dependencies brought in and updated, and then it turned out that the container with Go 1.13 was misconfigured so it literally had no access to that internal library, at all (something with Gitlab deploy keys...), so in a hurry we tried to vendor this internal library wholesale, and then there were some problems with gomod-ed libs and those without go.mod, and some linters had to be explicitly told to skip the 'vendor' directory (wtf), and... And at this point, I just stopped digging down that rabbit hole and instead added TESTIFY := github.com/stretchr/testify and mkdir -p "$(GOPATH)/src/$(TESTIFY)" ; git clone --depth 1 --branch v1.3.0 https://$(TESTIFY).git "$(GO
Read the rest
PATH)/src/$(TESTIFY)" before 'go install' in the build script, and ran it in the container with Go 1.10. This change took 5 minutes to make and worked without any problems. Isn't the one of the reasons we use semver in the first place so that after you do some small change to the current application you're working on, you don't suddenly find yourself having to update 2/3 of your the environment just to compile it?
In Go’s Major Versioning Sucks – From a Fanboy
You're not alone. I've been writing go since before 1.0, and can handle modules/packages in _any other language_ fine, yet go's regularly leaves me stumped. A little while ago we were hitting yet another issue with dependencies related to version pinning at work. I tried to divine what the disparate versions mean, and came up with this flow chart from a legalistic reading of stack overflow issues [1] and the go modules doc [2]: has the package opted into go modules (i.e. is there a go.mod?) yes does the repository use semver? yes is the major version <= 1? yes => normal versioning, e.g. github.com/stretchr/testify v1.3.0 no => when importing, we need add /vN at the end, e.g., import "github.com/my/mod/v4", and in go.mod it will behave like github.com/my/mod/
Read the rest
v4 v4.1.0 no => pseudo-versioning will be used, e.g. github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181 no does the repository use semver? yes is the major version <= 1? yes => pseudo-versioning will be used, e.g. github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181 no => version will be marked as incompatible, e.g. github.com/zeromq/goczmq v4.1.0+incompatible no => ??? I still don't know if this is right. But that's not really the point. I think the go authors painted themselves into a corner with such an anemic initial release. Now that they're trying to address shortcomings, the complexity is blowing up to handle the very large/diverse ecosystem. It reminds me a lot of java around 1.4 when they added in generics. In the long-run it was the right move, but man was it painful. 1: https://stackoverflow.com/a/57372286 2: https://github.com/golang/go/wiki/Modules
In Keeping your Go modules compatible

Showing the 15 most recent of 25 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.