junit-team/junit5 · error · JUnitException

Could not map TimeUnit <unit> to ChronoUnit

Error message

Could not map TimeUnit <unit> to ChronoUnit

What it means

Thrown by TimeoutDuration.toChronoUnit() when a java.util.concurrent.TimeUnit value does not map to one of the seven handled ChronoUnit constants. TimeUnit is a final enum with exactly seven values (NANOSECONDS through DAYS) and all seven are covered by the switch, so this default branch is effectively unreachable defensive code. It exists to satisfy exhaustiveness and guard against a hypothetical future TimeUnit constant.

Source

Thrown at junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/extension/TimeoutDuration.java:59

			label = label.substring(0, label.length() - 1);
		}
		return value + " " + label;
	}

	public Duration toDuration() {
		return Duration.of(value, toChronoUnit());
	}

	private ChronoUnit toChronoUnit() {
		return switch (unit) {
			case NANOSECONDS -> ChronoUnit.NANOS;
			case MICROSECONDS -> ChronoUnit.MICROS;
			case MILLISECONDS -> ChronoUnit.MILLIS;
			case SECONDS -> ChronoUnit.SECONDS;
			case MINUTES -> ChronoUnit.MINUTES;
			case HOURS -> ChronoUnit.HOURS;
			case DAYS -> ChronoUnit.DAYS;
			default -> throw new JUnitException("Could not map TimeUnit " + unit + " to ChronoUnit");
		};
	}
}

View on GitHub (pinned to 956246301e)

Solutions

1. This error should not occur under normal usage; verify you are using a stock JDK and standard TimeUnit values
2. If it does appear, file a bug against junit-jupiter-engine since the switch is missing a TimeUnit mapping

// TimeUnit is a fixed enum with exactly 7 values (NANOSECONDS..DAYS).
// No user validation is needed — all values are mapped.
// This branch is unreachable defensive code.
boolean isSupported = EnumSet.allOf(TimeUnit.class).contains(unit);
// Always true for any TimeUnit constant.

When it happens

Trigger: Calling new TimeoutDuration(value, unit).toDuration() where 'unit' is a TimeUnit constant not covered by the seven switch cases. Since TimeUnit has exactly seven constants and all are mapped, no standard input reaches this branch.

Common situations: Practically never encountered by end users. Could only surface if the JDK ever added a new TimeUnit constant without updating JUnit, or via reflection-based manipulation of the enum (not a real-world scenario).

Related errors

• thread mode must not be INFERRED
• Timeout duration is not in the expected format (<number> [ns
• Scheduled executor could not be stopped in an orderly manner
• Unsupported argument count validation mode: <mode>

AI-assisted analysis of junit-team/junit5@956246301e (2026-08-04). Data as JSON: /data/errors/3a1991fa54f4e45e.json. Report an issue: GitHub.