question / feature-suggestion: built-in way to overwrite / clear ExpectedCalls?

[jokeyrhyme]

Firstly, I love this library so much! Hooray! Thanks for sharing! <3

I'm using suite.Suite and mock.Mock and I have test suites where a number of tests share almost identical mocks, differing only where test-case-specific calls are mocked to fail (in order to test different failure conditions), e.g.

// something most of my `func Test...()`s need
suite.thing.On("DoSomething").Return(nil)
// image there are a dozen of those

// something just 1 or 2 of my `func Test...()`s need
suite.thing.On("DoSomething").Return(errors.New("something bad"))

The subject under test hits many functions like this, so I feel it is important for test confidence that I mock them all and assert that they are being called as expected, but so far I've achieved this with a lot of copy-pasting :)

I'd like to deduplicate my test file by having a common set of such mock.Mock.On(...) calls in my suite.Suite.SetupTest(), and just override them somehow for the specific tests where they need to be slightly different

Am I on the right path here, or have wandered off into weird territory?

What is the recommended way I should be testing something like this?

Is there a recommended way to undo a mock.Mock.On(...) or easily / safely modify mock.Mock.ExpectedCalls?

What if mock.Mock.On(...) replaced any Call in ExpectedCalls that had the same .Method and .Arguments?

Or, what if there was a more explicit mock.Mock.Off(...) that removed such a matching Call from ExpectedCalls?

Would you be interested in a PR for such things?

[devdinu]

I would ideally create a new mock for that particular test, which means the struct/interface which embeds the mock would be new. you could also write subtests for that particular case by grouping it.

You could do Mock.ExpectedCalls = nil , but ideally don't depend on the internals unless its really required. also it might cause other tests to fail, because it would be running those in parallel and the mock would be shared.

[edpark11]

FWIW I would also love a mock.Mock.ClearExpectedMethod... when executing unit tests where there is some setup and then many corner cases to be tested, the ability to clear anything with a particular methodname would be super helpful. Personally, I would be happy if this were a blunt call (i.e. anything with mock.ClearExpectedMethod("Foo").

[stephenjayakar]

why did this get closed out? especially considering the opened PR hasn't been approved or merged?

[sunhao1256]

you can use call func (c *Call) Times(i int) *Call
m.On("GetById", mockNotExistId).Return(&entity.NetworkEntity{Base: entity.Base{Id: mockNotExistId}}, mockNotExistErr).Times(1)

when you call on again , will return last call arguments

example

m.On("hello").Return("hello") m.On("hello").Return("hello1") m.MethodCalled("hello").Get(0) // hello m.MethodCalled("hello").Get(0) // hello1

[boyan-soubachov]

why did this get closed out? especially considering the opened PR hasn't been approved or merged?

@stephenjayakar , I had a look at it now. Not sure why the original author closed the PR. I've added a comment asking if they'd be happy to re-open and just change the name of the function from Off() to Unset()

[jmilic1]

Any progress on this?

[zaibon]

I usually use the following to reset the expected calls, but it would indeed be nice to have this exposed as part of the API of the mock object.

mock.ExpectedCalls = mock.ExpectedCalls[:0]

[javishere]

Any progress? I see this as a nice feature.

[gaston-haro]

Same here, use case is to have a tool to deal with setting correct expected parameters when order is not deterministic (due to map iteration for example). I set all possible variations of the call and then I would like to be able to reset everything.

[st3penta]

This issue has been solved by this PR with the introduction of the Unset method