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

nil-compare: false positives for assert.Equal(t, nil, value) (slice, channel) #36

Closed
dolmen opened this issue Nov 11, 2023 · 4 comments · Fixed by #55
Closed

nil-compare: false positives for assert.Equal(t, nil, value) (slice, channel) #36

dolmen opened this issue Nov 11, 2023 · 4 comments · Fixed by #55
Assignees

Comments

@dolmen
Copy link

dolmen commented Nov 11, 2023

assert.Equal(t, nil, []int(nil)) can't be replaced with assert.Nil(t, []int(nil)): the behaviour of testify is different, so nil-compare should not replace it.
Same issue for assert.Equal(t, nil, value) if value is of type chan struct{}.

See on the Go Playground: https://go.dev/play/p/jUxLF4j-w89

Note: I found this issue when applying testifylint on package github.com/stretchr/testify/mock: https://github.com/stretchr/testify/blob/db8608ed63f5bd9abdd03f669f5bb80569c114b6/mock/mock_test.go#L765

@dolmen
Copy link
Author

dolmen commented Nov 13, 2023

I wonder if the testsuite has a check that really executes the original test and the "fixed" test to verify that the behavior of testify is the same.
@Antonboom If that check exists, could you point me to it?

@Antonboom Antonboom self-assigned this Nov 14, 2023
@Antonboom
Copy link
Owner

Antonboom commented Nov 14, 2023

@dolmen, hi!

If that check exists, could you point me to it?

Before I just checked in playground, but from this issue I introduced some code (show you later).


About issue. It looks like Equal bug:

func ObjectsAreEqual(expected, actual interface{}) bool {
	if expected == nil || actual == nil {
		return expected == actual   // You cannot do this, because 
		                            // expected and actual are interfaces
	}

Equal is not consistent with Go ==:

var nilChan chan struct{}
fmt.Println(nilChan == nil)           // true
fmt.Println(any(nilChan) == any(nil)) // false

Also it affects assert.EqualValues(tm, nilChan, nil), because I expect this assertion passed, but this failed.

@dolmen
Copy link
Author

dolmen commented Nov 14, 2023

Whether there is a bug in Testify or not (that might be fixed in the future), testifylint should aim to work with Testify as it is now and even as it was in the past, because we can expect that users are applying (and will continue to apply) testifylint on codebases that still run older versions of Testify.

@Antonboom
Copy link
Owner

@dolmen

testifylint should aim to work with Testify as it is now

Totally agree, but not in this case. I dove deeper into your example and it's really a misuse of testify itself.
I described details here – stretchr/testify#1524

and even as it was in the past

It could be difficult, because some checkers use only fresh testify functions and features.
there is like in Go – support of the two last versions of testify 🙁

Thanks for issue! 🤝

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 a pull request may close this issue.

2 participants