[go-nuts] Re: Blog Article: Go Generics (and also mocking)

['TheDiveO' via golang-nuts]

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. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c1283f0a-0380-4fe7-aa45-b57baa34b9abn%40googlegroups.com.

[go-nuts] Re: Blog Article: Go Generics (and also mocking)

[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...

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ff9a7dcc-7594-4674-b7c5-56205007e12en%40googlegroups.com.

[go-nuts] Re: Blog Article: Go Generics (and also mocking)

[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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/83b6fb46-41e5-45dd-afe6-f66a4c315d3fn%40googlegroups.com.

[go-nuts] Re: Blog Article: Go Generics (and also mocking)

['TheDiveO' via golang-nuts]

  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. 
On Monday, January 8, 2024 at 3:39:31 AM UTC+1 Corin Lawson wrote:

> 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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9b791784-cb6d-4bbb-af67-3489701a4f84n%40googlegroups.com.