Go Assertion Frameworks

What options are out there? I have played around with testify but it seems like the PRs on the GitHub repo are all quite stale? also I really want to be able to name my tests in snake case and not camel case.

---

评论：

nemith:

My suggestion is to not use an assertion library.  Doing standard if statements and calling t.Errorf or t.Fatalf goes a long way and I think it makes for more meaningful tests.

The assertion libraries are really light wrappers around this and there is no reason why they would need "updating".

As for test names, if you want to use the Go testing framework the function must start with Test.  The rest is up to you, however i would strongly suggest trying to stick with proper go style.  It may feel weird at first, but it's better to get used to it, as all the libraries and stdlib are going to follow that styling anyway.

mcandre:

Seconded. I personally hate having to relearn yet another stupid framework when adding tests to a suite. Less is more.

jerf:

One thing that I suspect is an apparently blocker for some people is when they don't know about reflect.DeepEqual. But it is in the standard library.

There is a library or libraries on github that can stand in for reflect.DeepEqual and tell you what the differences are instead of just returning true or false. I don't leave them in my code in the long term but it's useful for debugging. (I'd go find them but I'm getting rushed out the door.)

Edit: Now that I'm not under time pressure, https://godoc.org/github.com/go-test/deep .

nemith:

I have found  Google's own cmp https://github.com/google/go-cmp to be very friendly for these needs.

GodsBoss:

I used to use testify/assert (you seem to refer to it, too), but have switched to vanilla testing for several reasons.

First, you have to manage one more dependency. This may be fine for bigger projects where you need dependency management anyways, but for small, self-contained libraries this could mean introducing it, which is a big step, relatively.

Second, it is something every developer has to learn. It is fair game to assume that developers know the standard testing package, and if not, they would have to learn it either way. Learning an assertion API is an additional obstacle.

There are also disadvantages, I must admit. You have to write a bit more code, especially for tests like the ones I wrote recently where items (with specific properties) should be contained in a slice, but at what index wasn't defined. This can mean writing a few lines, wheras with an assertion framework you would have written a one-liner.

But I still think the cons (against an assertion framework) outweigh the pros.

kostix:

I very much advise you to take your time and watch The Three Fallacies of Dependencies by Blake Miserany — it's fun to watch and it deals precisely with your use case ;-)

rz2yoj:

I've been using testify for a long time now, on both big and small projects, and I'm really uncompelled by statements like "vanilla testing makes for more meaning tests" or "it's one more thing every developer has to learn". I'm not convinced of the former, and while the latter one is true, the learning curve for testify is very small. If you're just using testify's assert/require packages, every developer that looks at your tests is going to find it intuitively obvious how to use it.

I've found time and time again that when your project uses only the standard testing package, the output when tests fail tends to be completely useless. People don't like spending a lot of time writing tests and often just throw in t.Fail() statements rather than figuring out and printing the actual and expected outputs of their test subjects.

Don't be put off by testify's lack of updates. Its assert/require packages are pretty much feature complete, and I would recommend them.

adamcolton:

I'd second this. I've had great results with testify/assert. I like it's functions for Equal, Len, NoError and NotNil. That's about 90% of what I use it for. And (this may be obvious, but still...) using it doesn't mean you have to only use it. Write vanilla tests where it makes sense, use the assert helpers where they make sense.

And the point about formatting is not a trivial one. The assert.Equal has a nice feature that if you give it two byte slices and they are not equal it will show just the differences. That saved me a big headache once.

Finally, slightly off topic but... write table tests where you can.

ar1819:

testify and goconvey are amongst most used. Also, you might want to look into github.com/kindrid/gotest.

But I agree with others - try built-in test package and see if it works for you.

mmatczuk:

Try https://github.com/google/go-cmp it usually solves all the problems with assertions. You do a normal if and get a diff like in python or groovy.