Blog Article: Go Generics (and also mocking)

[Corin Lawson]

I recently published a blog post about Go generics.  I've found that there's lots of very good technical information about generics in Go, but I felt that they are lacking some gritty experience reports.

https://medium.com/versent-tech-blog/go-generics-tips-tricks-and-pitfalls-4342b82f9eeb

The blog also introduces a new approach to generating mock objects in Go.

https://github.com/Versent/go-mock

I'm seeking feedback (as an inexperienced blogger) and also thoughts on the mock lib (apologies for the lack of naming creativity),

Thanks for your time.

[TheDiveO]

  a quick first lock looks promising to me: I like the blog post, as it does IMHO a gentle introduction to your angle of attack. Having used mocking (or one of its twins/cousins/... for those who insist on this not being mocking, alas) on Python I've up to now found the Go mock packages to be difficult and with rather unwelcoming documentation.   As for the naming: kudos for naming it what it is, clear and concise, imagination be reserved to where it applies, not just here.

[TheDiveO]

One thing I notice is that your design assumes to specify the expected call sequence upon creation, or do I get this wrong? My expectation would be to specify this only at the assertion site.

Since starting with Go I've been in love with Ginkgo/Gomega, as this is more on the level what I was working with in Python, compared to bare-footed Go testing ... is there a way to have the assertion of call sequence being independent of testing, such as returning what was expected and what it got? That is, something that allows it being used (with a wrapper) as a Gomega matcher...? 

On Monday, January 8, 2024 at 3:39:31 AM UTC+1 Corin Lawson wrote:

[Mike Schinkel]

On Sunday, January 7, 2024 at 9:39:31 PM UTC-5 Corin Lawson wrote:

also thoughts on the mock lib (apologies for the lack of naming creativity),

On Monday, January 8, 2024 at 9:00:24 AM UTC-5 TheDiveO wrote:

As for the naming: kudos for naming it what it is, clear and concise

A different perspective: Given the nature of Go package names and imports, I find it regrettable when people Go packages have generic names that have a high likelihood of conflicting with other package names.  

When it's for your own use, especially internal and not on a team, it's typically less problem. However, when the intent is to publish and encourage others to use I would respectfully advocate for a name that is not likely to be duplicated by someone else who is lacking in naming creativity. 

Certainly, when there are conflicts in names people can use aliases for their imports, as aliases were intended.  When programming one's own side project app, using aliases typically doesn't become a big problem. 

However, when working on a Go codebase with tens or hundreds of developer those same-named packages quickly become a nightmare of differently named aliases making it really hard to tell what-is-what when looking at code in a complex codebase. IOW, which "util" is being used when "util2.DoStuff()" is called?  And believe me, I have seen a ton of this kind of aliasing in production code.

My comments apply even more to CLI tools like 'mockgen' in this case because, while aliases are available on a CLI, it can cause problems for initial and ongoing setup for the tool.

On Monday, January 8, 2024 at 9:00:24 AM UTC-5 TheDiveO wrote:

imagination be reserved to where it applies, not just here.

It doesn't have to be imaginative nor obfuscated to be cognizant of naming conflicts.  

Rather than "go-mock" it would be better IMO if the OP had named it (something like) "go-vermock"  (the company he works for is Versant) and if he chose to name his CLI "vermockgen," or similar.

-Mike

#jmtcw #fwiw

[Corin Lawson]

On Tuesday 9 January 2024 at 3:33:42 am UTC+11 Mike Schinkel wrote:

It doesn't have to be imaginative nor obfuscated to be cognizant of naming conflicts. 

Thanks, you've convinced me that it needs to change so I'll do it now and I might steal that name (vermock)!

On Tuesday 9 January 2024 at 1:12:00 am UTC+11 TheDiveO wrote:

One thing I notice is that your design assumes to specify the expected call sequence upon creation, or do I get this wrong? My expectation would be to specify this only at the assertion site.

That's correct, there is mock.Expect and mock.ExpectInOrder, that is used when you setup the test and only one mock.AssertExpectedCalls.  It would be feasible to introduce functions, say mock.AssertExpectedCallsInOrder and mock.AssertExpectedCallsInAnyOrder, which would change the meaning of mock.Expect (currently it assumes that the calls may occur in any order) and a explicit version could be introduced, say mock.ExpectInAnyOrder.  I think it's simpler to have a single mock.AssertExpectedCalls function, and making mock.Expect implicitly do one thing in one test and a different thing in another test is asking for trouble. The mock.AssertExpectedCalls function is designed to be used in a table driven testing pattern and individual tests in the table can provide a mock that is correctly configured, while the main body of the test simply calls mock.AssertExpectedCalls without needing to know anything else about the test.  But I would like to know more about your point of view, I haven't seen other mocking libraries make this determination at the assertion site.  Can you show me what you mean?

Since starting with Go I've been in love with Ginkgo/Gomega, as this is more on the level what I was working with in Python, compared to bare-footed Go testing ... is there a way to have the assertion of call sequence being independent of testing, such as returning what was expected and what it got? That is, something that allows it being used (with a wrapper) as a Gomega matcher...?

Gomega is very nice, I think it needs a certain level of buy-in, but once you make that choice there's some cool features... I'll have to have a closer look at gomega matchers...

[TheDiveO]

On Tuesday, January 9, 2024 at 2:28:08 AM UTC+1 Corin Lawson wrote:

On Tuesday 9 January 2024 at 1:12:00 am UTC+11 TheDiveO wrote:

One thing I notice is that your design assumes to specify the expected call sequence upon creation, or do I get this wrong? My expectation would be to specify this only at the assertion site.

That's correct, there is mock.Expect and mock.ExpectInOrder, that is used when you setup the test and only one mock.AssertExpectedCalls.  It would be feasible to introduce functions, say mock.AssertExpectedCallsInOrder and mock.AssertExpectedCallsInAnyOrder, which would change the meaning of mock.Expect (currently it assumes that the calls may occur in any order) and a explicit version could be introduced, say mock.ExpectInAnyOrder.  I think it's simpler to have a single mock.AssertExpectedCalls function, and making mock.Expect implicitly do one thing in one test and a different thing in another test is asking for trouble. The mock.AssertExpectedCalls function is designed to be used in a table driven testing pattern and individual tests in the table can provide a mock that is correctly configured, while the main body of the test simply calls mock.AssertExpectedCalls without needing to know anything else about the test.  But I would like to know more about your point of view, I haven't seen other mocking libraries make this determination at the assertion site.  Can you show me what you mean?

Basically Python's unittest.mock -- hopefully I'm not considered a heretic now :D -- https://docs.python.org/3/library/unittest.mock.html; now I understand that Python (or Lua FWIW) allow very convenient mocking due to their dynamic meta-model runtime...

from unittest.mock import MagicMock

thing = ProductionClass()

thing.method = MagicMock(return_value=3)

thing.method(3, 4, 5, key='value')

3

thing.method.assert_called_with(3, 4, 5, key='value')

Somehow that would be my expectation (literally coming from the Gomega background) that I can more flexibly do complex sequences on the mock without having to tell the mock the complete sequence beforehand. I personally like this unittest.mock style because it allows me to do a step-wise assertion/expectation approach that gives me more fine-grained reporting in case of assertion failure. Otherwise, it's a big mess and I need to sort out where exactly it started to go south.

Now this is probably more specific to my field of Go work, but I regularly have more complex unit tests that cannot really be sensibly spread into many individual -- to use Ginkgo terminology -- "It" leaf test nodes.

Since starting with Go I've been in love with Ginkgo/Gomega, as this is more on the level what I was working with in Python, compared to bare-footed Go testing ... is there a way to have the assertion of call sequence being independent of testing, such as returning what was expected and what it got? That is, something that allows it being used (with a wrapper) as a Gomega matcher...?

Gomega is very nice, I think it needs a certain level of buy-in, but once you make that choice there's some cool features... I'll have to have a closer look at gomega matchers...

Coming from the Python ecosystem and starting seriously with Go 1.11/Go 1.12 when modules finally landed, I personally found the std testing to be very bare bones (which is fine considering the Go mantra here). So I looked what the really huge projects do, and this was in my case k8s :D -- I liked immediately what they used, as it was a comparably logical transition from Python expectation packages to Gomega and Ginkgo.

Disclaimer: I contributed the Go routine leak checker to Gomega after coming to the conclusion that the incredibly useful Uber go routine leak checker was too deeply intertwined with testing and couldn't be conveniently reused in Gomega.