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.
