Go testing: your approach and opinion

The discussion related to testing in Go is huge in the Internet. I’ve read a lot about this. I don’t want anyone to compare any of that here. Instead, I would like to learn your opinion, your feelings, your reasoning.

I must admit at first when I came to Go I immediately missed assert. I wrote a couple of my assert-like functions, then discovered testify, and then… And then gave up testify and deleted my own functions. Now I do appreciate the simplicity of testing in classical testing. It’s indeed lightweight. It indeed does not require one to learn a sublanguage. For the moment, I have not even once missed anything — and I have already written a couple of hundreds of tests (I LOVE writing tests — don’t ask my why), many benchmarks (just LOVE them!) and examples (just LOVE them!).

What do you think about testing in Go? Do you use more advanced testing frameworks in Go, like testify? Or do you follow the same path as I do, so use the basic testing approach, not because you do not have time to learn testify (well, it does not need much time to learn, does it?) but because you do agree with Go’s creators that the basic approach is what you need and like?

And maybe there are situations in which the basic approach does not suffice? If this is the case, I would be happy to hear about them, at the very least to be prepared when my time comes to struggle with them.

Depending on how you maintain your package. I find most guides outside are only suitable for small and basic packages.

I wrote a paper about large scale unit testing in Go without needing extra frameworks and only needs habit. Personally I use BDD more than TDD for testing because of the on-going cumbersome maintenance costs.

1 Like

Thanks for sharing — it’s an interesting paper!

And thanks for your opinion. For me it’s difficult to imagine big projects because I am a data scientist and my programs seldom go over several thousands of lines, and quite often it’s just a couple of hundred. But I see the point you’re making in the paper, and I can imagine the growing complexity of both the main code and the testing code in case of huge packages.