stretchr/testify · error
expected value must have a value other than zero to calculat
Error message
expected value must have a value other than zero to calculate the relative error
What it means
Returned by calcRelativeError (assert/assertions.go:1566) when the expected value converts to 0.0. Relative error is computed as |expected-actual|/|expected| (assert/assertions.go:1573), so a zero denominator is undefined; testify refuses to compute it. Surfaced through assert.InEpsilon.
Source
Thrown at assert/assertions.go:1567
}
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...)
}
actualEpsilon, err := calcRelativeError(expected, actual)
if err != nil {View on GitHub (pinned to 001eb7946b)
Solutions
- Use assert.InDelta(t, 0.0, actual, absTol) for absolute tolerance instead of relative when the expected baseline is zero.
- If zero is genuinely the expected value, use assert.Equal(t, 0.0, actual) or assert.InDelta with a small absolute bound.
- Shift the baseline so expected is non-zero before computing relative error.
Example fix
// before assert.InEpsilon(t, 0.0, reading, 0.05) // after assert.InDelta(t, 0.0, reading, 0.05)
Defensive patterns
Strategy: validation
Validate before calling
ef, ok := asFloat(expected)
if ok && ef == 0 {
t.Log("expected is zero; using InDelta instead")
assert.InDelta(t, expected, actual, absTol)
return
}
assert.InEpsilon(t, expected, actual, eps) Type guard
func isNonZeroNumeric(v interface{}) bool {
f, ok := asFloat(v)
return ok && f != 0 && !math.IsNaN(f)
} Try / catch
// Choose assertion based on expected magnitude:
if f, ok := asFloat(expected); ok && f == 0 {
assert.InDelta(t, expected, actual, absTol)
} else {
assert.InEpsilon(t, expected, actual, eps)
} Prevention
- Default to InDelta for absolute tolerance when baselines can be zero.
- Parameterize tolerance helpers to pick InDelta vs InEpsilon by magnitude.
- Document that InEpsilon is undefined for zero expected values.
When it happens
Trigger: Calling assert.InEpsilon(t, 0.0, actual, eps) or assert.InEpsilon(t, int(0), actual, eps). Also when expected is a numeric type whose value happens to be zero.
Common situations: Asserting tolerance against a baseline/expected of zero (e.g. measuring drift from a zero starting point), or testing near-zero sensor readings where absolute tolerance, not relative, is appropriate.
Related errors
- Parameters must be numerical
- expected value must not be NaN
- actual value must not be NaN
- cannot take func type as argument
AI-assisted analysis of stretchr/testify@001eb7946b (2026-08-04).
Data as JSON: /data/errors/05f18d2fc83bdc3e.json.
Report an issue: GitHub.