Skip to content

Conversation

brackendawson
Copy link
Collaborator

Fix a panic in the AnythingOfType matcher when matching nil type.

It's reported that IsType had the same panic but a refactor between then and now appears to have fixed this.

Summary

Changes

  • Handle the nil type case before calling reflect.Type.String.
  • Because (=) looks confusing, change the failure message value format to the more idiomatic (%T)(%v).
  • In order to better test the failure message, change the mockTestingT to capture the messages passed to it.

Motivation

AnythingOfType would panic if the actual arg value was of type nil.

Related issues

Comment on lines 1918 to 1919
assert.Contains(t, diff, `(int)(456) != (int)(123)`)
assert.Contains(t, diff, `(string)(false) != (bool)(true)`)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This format seems awkward to me.

I feel like we are using something like this everywhere else

Suggested change
assert.Contains(t, diff, `(int)(456) != (int)(123)`)
assert.Contains(t, diff, `(string)(false) != (bool)(true)`)
assert.Contains(t, diff, `456(int) != 123(int)`)
assert.Contains(t, diff, `false(string) != true(bool)`)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Think about something storing "bool" in a string. The result is confusing

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

(string)(false) is a bit confusing. However *int(1) is also confusing because it's invalid in go. I'm going to restore the original format.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm a bit lost there

I was suggesting to use "false (string)"

I felt like it was better than "(false)(string)"

So the example of "*int(1)" is incorrect. I was asking to use "1 (*int)" (even if I'm unsure this format exists as you said)

My point was to use something like "%v (%T)" that we are already using. And fix the strange format that exists in code for this method.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I mis-read your suggestion, %v(%T) is also quite weird to me because I was hoping to find something with a grounding in Go syntax.

This probably warrants de-coupling into a separate issue where we can consider the format we want testify to move to as a whole. As I said for now this PR just fixes the panic and leaves the format alone.

@brackendawson brackendawson force-pushed the 1209-mock-argument-nil-type-panic branch 3 times, most recently from a81fbc5 to 6b9ffdf Compare September 19, 2025 11:52
AnythingOfType would panic if the actual arg value was of type nil. Handle the nil type case before calling reflect.Type.String.

Because (<nil>=<nil>) looks confusing, change the failure message value format to the more idiomatic (%T)(%v).

In order to better test the failure message, change the mockTestingT to capture the messages passed to it.
@brackendawson brackendawson force-pushed the 1209-mock-argument-nil-type-panic branch from 6b9ffdf to 564214b Compare September 19, 2025 11:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Mock panics when argument of nil type checked against AnythingOfType
2 participants