stretchr/testify · error

actual value must not be NaN

Error message

actual value must not be NaN

What it means

Returned by calcRelativeError (assert/assertions.go:1569) when the actual value converts to math.NaN() while expected is a valid (non-NaN, non-zero) number. A NaN actual makes the relative error meaningless, so testify rejects it. Surfaced through assert.InEpsilon.

Source

Thrown at assert/assertions.go:1570

}

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...)
	}
	actualEpsilon, err := calcRelativeError(expected, actual)
	if err != nil {
		return Fail(t, err.Error(), msgAndArgs...)
	}
	if math.IsNaN(actualEpsilon) {

View on GitHub (pinned to 001eb7946b)

Solutions

1. Add a math.IsNaN guard on the actual value before asserting and fail with a descriptive message.
2. Fix the upstream code path that produced NaN (validate inputs, guard divisions).
3. If NaN actual is expected behavior, assert it explicitly: assert.True(t, math.IsNaN(actual)).

Example fix

// before
assert.InEpsilon(t, want, result, 0.01) // result may be NaN
// after
if math.IsNaN(result) {
    t.Fatalf("result is NaN, want %v", want)
}
assert.InEpsilon(t, want, result, 0.01)

if f, ok := asFloat(actual); ok && math.IsNaN(f) {
    t.Fatalf("actual is NaN; cannot compute relative error")
}
assert.InEpsilon(t, expected, actual, eps)

func actualIsNotNaN(v interface{}) bool {
    f, ok := asFloat(v)
    return ok && !math.IsNaN(f)
}

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

When it happens

Trigger: Calling assert.InEpsilon(t, expected, math.NaN(), eps) where actual is NaN — typically the output of a buggy computation (0/0, invalid sqrt, unchecked float parse).

Common situations: Production code under test produces NaN from an unchecked arithmetic path (divide by zero, log of negative), and that value flows into a tolerance assertion. Common in numerical/financial/ML test suites.

Related errors

• expected 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/9d07340ced90b494.json. Report an issue: GitHub.