NotEqual tests equality for different types

[momoneko]

NotEqual does not complain when you try to test values of different types.

For example, if I run go test with this code, it passes just fine.

package main

import (
	"testing"

	"github.com/stretchr/testify/assert"
)

func TestBeep(t *testing.T) {
	assert.NotEqual(t, 1, "Hello")
}

It should loudly complain, or, even better, not compile.

[ernesto-jimenez]

@momoneko what is the use case?

Semantically, it makes sense that test would pass because those two values are different. Changing NotEqual to make that test fail would be a backwards-incompatible change.

Furthermore, these checks will always be in runtime and the code will always build. It's impossible for testify to make a compilation fail with code like that.

For type checking, whenever possible I prefer letting the compiler do the checks and fail the compilation if invalid.

If you want to actually check the types with assert, you can use assert.IsType.

[momoneko]

I noticed this while rewriting tests of the form: Assert(x == y, "Some error message") and I made a mistake by not replacing == to a comma, result in t.Equal(x == y, "Some error message").

Why failing that test would be backwards-incompatible? Go is not a dynamic language to have a valid use case for comparing strings to ints. Any attempt to do that is most likely a mistake and should be treated as such.

[mbeachy]

This means that simple typos can end up as passing but meaningless tests, e.g. assert.NotEqual(case1, case2.Field).

What's the use case for this behavior?

It would be a backwards incompatible change, but the simplest way out of this situation that I can think of is to change it.

Introducing a new method (e.g. assert.SameTypesNotEqual) seems clunky because the most often used case should be connected with the simplest name.