Live data from Hacker News

Ask HN: How to approach testing in Golang?

news.ycombinator.com

1–10 of 37 posts

Ask HN: How to approach testing in Golang?

#1
I am a bit lost when it comes to unit testing in Golang. When developing in Java and Javascript it is easy to mock out data and functions, make assertions and expectations such as making sure some function was called inside a function your testing. What are some things to make sure to test when unit testing Golang functions and what is a good strategy for mocking things out?

Re: Ask HN: How to approach testing in Golang?

#2
Take a look at the Golang source for some examples of table-driven tests. When you need mocking you can usually use interfaces and then define a struct in your test that satisfies the methods of the interface.

I'm currently co-authoring a book called Production Go which includes a chapter on testing. That chapter is available in the free sample: https://leanpub.com/productiongo/ and might cover some of your questions.

Re: Ask HN: How to approach testing in Golang?

#3
If you want to make testing a bit less verbose, you can look into testify (https://github.com/stretchr/testify), it adds some helpful assertions (no more 'if err != nil ...').

If you are using interfaces with dependency injection, it is easy to mock the dependencies of whatever you are unit testing implementing the interfaces you have defined in your testing file.

Re: Ask HN: How to approach testing in Golang?

#4
Check out https://github.com/stretchr/testify for more convenient assertions, as well as mocking support for implementing interfaces within your tests.

You cannot do ad-hoc mocking of arbitrary functions in Go. If you want to write component-level tests that mock out other components, then you need an interface boundry between those components. Or better yet, you just write tests at the network level, spinning up mock clients/servers on localhost.

Re: Ask HN: How to approach testing in Golang?

#6
post #4

Check out https://github.com/stretchr/testify for more convenient assertions, as well as mocking support for implementing interfaces within your tests. You cannot do ad-hoc mocking of arbitrary functions in Go. If you want to write component-level tests that mock out other components, then you need an interface boundry between those components. Or better yet, you just write tests at the network level, spinning up moc…

I find vanilla Go testing (if res != exp { t.Fatal(...) }) much more versatile than testify. Testify did not cover some of my mocking use cases, and response on the repo was tepid, so I ditched it and was happier (this is a user POV, please don't come bashing me on not contributing to open source, etc.)

For mocks, I use GoMocks (https://github.com/golang/mock), again a "standard" lib of go. It has Expect syntax where you can assert that mocks were called in a certain way.

I use `go generate` to generate my mocks via interfaces. You should be comfortable with abstracting your specific implementation with interfaces. It is like the first must-do step to Go testing, since we cannot monkey patch or duck type stuff on the fly unlike in JS or Ruby... Second step is to generate mocks from the interface, and inject these dependencies into say your API HTTP Handler... Third step is to assert that your mocks were called in a certain way, and you can also craft different return values from your mocks, to test different scenarios. I also extended some of the gomock Matchers to be able to return different stuff on the fly for e.g in the case of row.Scan(&ptrToInt, &ptrToString), etc.

Ultimately I think this is the Golang ethos: Stick to the standard way of doing things, even if you are allergic to it at first. You will be happier.

Re: Ask HN: How to approach testing in Golang?

#7
I have recently created a small project called rocket (https://github.com/joernlenoch/rocket) to provide myself with a simple dependency injection module for exactly this reason.

This is rather a starting point than a solution for your problem. But combined with some "fakers" and supplied testing frameworks this might remove some of the boilerplate.

Post reply on HN