You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In case of a panic inside MethodCalled, the mock mutex is not released. All subsequent calls to mock methods will block and the test will timeout eventually.
This is a problem if we use testing Cleanup to call AssertExpectations -- like what mockery does on each mock constructor.
Step To Reproduce
create a mock instance and use testing Cleanup to verify the state
perform some action that will eventually panic
wait until the test timeout
Expected behavior
I expect having a clear panic ASAP. Or a better expectation/ failure instead a raw panic.
Actual behavior
It panics but the Cleanup blocks the code until timeout, hiding the root cause
484// MethodCalled tells the mock object that the given method has been called, and gets485// an array of arguments to return. Panics if the call is unexpected (i.e. not preceded486// by appropriate .On .Return() calls)487// If Call.WaitFor is set, blocks until the channel is closed or receives a message.488func (m*Mock) MethodCalled(methodNamestring, arguments...interface{}) Arguments {
489m.mutex.Lock()
490// TODO: could combine expected and closes in single loop491found, call:=m.findExpectedCall(methodName, arguments...)
we could do this generic fix to just force release the lock
484// MethodCalled tells the mock object that the given method has been called, and gets485// an array of arguments to return. Panics if the call is unexpected (i.e. not preceded486// by appropriate .On .Return() calls)487// If Call.WaitFor is set, blocks until the channel is closed or receives a message.488func (m*Mock) MethodCalled(methodNamestring, arguments...interface{}) Arguments {
489m.mutex.Lock()
deferfunc(){
ifr:=recover(); r!=nil {
_=m.mutex.TryUnlock() // REQUIRES go 1.18panic(r) // throw the panic again
}
}()
490// TODO: could combine expected and closes in single loop491found, call:=m.findExpectedCall(methodName, arguments...)
The text was updated successfully, but these errors were encountered:
Description
In case of a panic inside MethodCalled, the mock mutex is not released. All subsequent calls to mock methods will block and the test will timeout eventually.
This is a problem if we use testing Cleanup to call AssertExpectations -- like what mockery does on each mock constructor.
Step To Reproduce
Expected behavior
I expect having a clear panic ASAP. Or a better expectation/ failure instead a raw panic.
Actual behavior
It panics but the Cleanup blocks the code until timeout, hiding the root cause
Code Example
then executing
if I comment the t.Cleanup call I have this
I find a possible fix, on the original code:
we could do this generic fix to just force release the lock
The text was updated successfully, but these errors were encountered: