Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixing panic in calls to assertion with nil m.mutex #1212

Merged
merged 4 commits into from Jun 24, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
16 changes: 3 additions & 13 deletions mock/mock.go
Expand Up @@ -255,7 +255,7 @@ type Mock struct {
// this data completely allowing you to do whatever you like with it.
testData objx.Map

mutex *sync.Mutex
mutex sync.Mutex
}

// String provides a %v format string for Mock.
Expand All @@ -282,10 +282,6 @@ func (m *Mock) TestData() objx.Map {

// Test sets the test struct variable of the mock object
func (m *Mock) Test(t TestingT) {
if m.mutex == nil {
m.mutex = &sync.Mutex{}
}

m.mutex.Lock()
defer m.mutex.Unlock()
m.test = t
Expand Down Expand Up @@ -316,9 +312,6 @@ func (m *Mock) On(methodName string, arguments ...interface{}) *Call {
}
}

// Since we start mocks with the .On() function, m.mutex should be reset
m.mutex = &sync.Mutex{}

m.mutex.Lock()
defer m.mutex.Unlock()
c := newCall(m, methodName, assert.CallerInfo(), arguments...)
Expand Down Expand Up @@ -526,9 +519,9 @@ func AssertExpectationsForObjects(t TestingT, testObjects ...interface{}) bool {
h.Helper()
}
for _, obj := range testObjects {
if m, ok := obj.(Mock); ok {
if m, ok := obj.(*Mock); ok {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure this should be changed? IIRC I didn't change this logic in the PR I merged?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, because we want to refer to the same instance of sync.Mutex for the copy that is a type check here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, go vet ./... will show that warning for us ( It was caught in CI).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough; I see it's a test helper anyways.

Thank you for catching this!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦 . I must've missed this when doing the Go 1.18 PR (which broke this) and 'fixed it' the long way around. Thanks

t.Logf("Deprecated mock.AssertExpectationsForObjects(myMock.Mock) use mock.AssertExpectationsForObjects(myMock)")
obj = &m
obj = m
}
m := obj.(assertExpectationser)
if !m.AssertExpectations(t) {
Expand All @@ -545,9 +538,6 @@ func (m *Mock) AssertExpectations(t TestingT) bool {
if h, ok := t.(tHelper); ok {
h.Helper()
}
if m.mutex == nil {
m.mutex = &sync.Mutex{}
}

m.mutex.Lock()
defer m.mutex.Unlock()
Expand Down