stretchr/testify · error

expected value must not be NaN

Error message

expected value must not be NaN

What it means

Returned by calcRelativeError (assert/assertions.go:1563) when the expected value, after conversion via toFloat, is math.NaN() (and actual is not also NaN). A NaN expected value makes relative-error math meaningless, so testify rejects it explicitly. Surfaced through assert.InEpsilon.

Source

Thrown at assert/assertions.go:1564

		) {
			return false
		}
	}

	return true
}

func calcRelativeError(expected, actual interface{}) (float64, error) {
	af, aok := toFloat(expected)
	bf, bok := toFloat(actual)
	if !aok || !bok {
		return 0, fmt.Errorf("Parameters must be numerical")
	}
	if math.IsNaN(af) && math.IsNaN(bf) {
		return 0, nil
	}
	if math.IsNaN(af) {
		return 0, errors.New("expected value must not be NaN")
	}
	if af == 0 {
		return 0, fmt.Errorf("expected value must have a value other than zero to calculate the relative error")
	}
	if math.IsNaN(bf) {
		return 0, errors.New("actual value must not be NaN")
	}

	return math.Abs(af-bf) / math.Abs(af), nil
}

// InEpsilon asserts that expected and actual have a relative error less than epsilon
func InEpsilon(t TestingT, expected, actual interface{}, epsilon float64, msgAndArgs ...interface{}) bool {
	if h, ok := t.(tHelper); ok {
		h.Helper()
	}
	if math.IsNaN(epsilon) {
		return Fail(t, "epsilon must not be NaN", msgAndArgs...)

View on GitHub (pinned to 001eb7946b)

Solutions

1. Guard the expected value with math.IsNaN before calling InEpsilon and skip/fail the test explicitly.
2. Fix the upstream computation that produced NaN (check for divide-by-zero, invalid log/sqrt inputs).
3. If NaN-expected is legitimately possible, use assert.True(t, math.IsNaN(actual)) instead.

Example fix

// before
assert.InEpsilon(t, computed, want, 0.01) // computed may be NaN
// after
if math.IsNaN(computed) {
    t.Fatal("computed is NaN")
}
assert.InEpsilon(t, computed, want, 0.01)

ef, ok := toFloatLike(expected)
if !ok || math.IsNaN(ef) {
    t.Fatalf("expected is NaN, cannot compute relative error")
}
assert.InEpsilon(t, expected, actual, eps)

func isNotNaNFloat(v interface{}) bool {
    f, ok := toFloatPublic(v) // mirror of assert.toFloat
    return ok && !math.IsNaN(f)
}

// Guard the expected value before asserting:
if f, ok := asFloat(expected); ok && math.IsNaN(f) {
    t.Fatalf("expected is NaN")
}
assert.InEpsilon(t, expected, actual, eps)

When it happens

Trigger: Calling assert.InEpsilon(t, math.NaN(), actual, eps) where expected evaluates to NaN — e.g. the result of 0.0/0.0 or an unchecked math operation that produced NaN.

Common situations: Divide-by-zero or sqrt-of-negative producing NaN that flows unchecked into a tolerance assertion; results from external computation (CSV parsing, ML model output) that occasionally yields NaN.

Related errors

• actual value must not be NaN
• Parameters must be numerical
• expected value must have a value other than zero to calculat
• cannot take func type as argument

AI-assisted analysis of stretchr/testify@001eb7946b (2026-08-04). Data as JSON: /data/errors/ae92357b64adb89d.json. Report an issue: GitHub.