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.
