junit-team/junit5 · error · ParameterResolutionException

Failed to resolve parameter

Error message

Failed to resolve parameter [%s] in %s [%s]

What it means

Generic wrapper thrown when the chosen ParameterResolver.resolveParameter throws any non-unrecoverable Throwable during parameter resolution. It attaches the resolver-independent context (parameter, executable label, generic signature) and appends the underlying message. ParameterResolutionException from the resolver itself (e.g. the no-resolver / multi-resolver cases) is rethrown as-is without wrapping.

Solutions

  1. Read the appended ': <cause message>' suffix to locate the underlying resolver failure and fix it.
  2. Verify all configuration the resolver needs (system properties, env vars, base URLs) is present at test time.
  3. If you own the resolver, throw ParameterResolutionException directly with a helpful message so users see it unwrapped.

Example fix

// before
@Override
public Object resolveParameter(ParameterContext pc, ExtensionContext ec) {
    return client.findBean(pc.getParameter().getType()); // throws when service down
}
// after
@Override
public Object resolveParameter(ParameterContext pc, ExtensionContext ec) {
    Class<?> t = pc.getParameter().getType();
    if (!client.isAvailable())
        throw new ParameterResolutionException("resolver backend unavailable");
    return client.findBean(t);
}
Defensive patterns

Strategy: try-catch

Try / catch

try {
    runTests(MyTest.class);
} catch (ParameterResolutionException e) {
    log.error("parameter resolution failed: {}", e.getMessage(), e.getCause());
    throw e;
}

Prevention

When it happens

Trigger: resolver.resolveParameter(...) throws - e.g. resolver cannot contact its backing service, reflection on the parameter fails, resolver logic has a bug, or the underlying factory object construction fails.

Common situations: A Testcontainers/HttpClient resolver whose backing resource is unavailable; a resolver that calls a remote service to build the parameter; misbehaving third-party extension throwing inside resolveParameter; missing config the resolver needs.

Related errors


AI-assisted analysis of junit-team/junit5@f070c699a0 (2026-08-11). Data as JSON: /api/errors/90c3043a7b91c88b. Report an issue: GitHub.

Appendix: source

Thrown at junit-jupiter-engine/src/main/java/org/junit/jupiter/engine/execution/ParameterResolutionUtils.java:174

					resolver.getClass().getName(), (value != null ? value.getClass().getTypeName() : null),
					parameterContext.getParameter(), asLabel(executable), executable.toGenericString()));

			return value;
		}
		catch (ParameterResolutionException ex) {
			throw ex;
		}
		catch (Throwable throwable) {
			UnrecoverableExceptions.rethrowIfUnrecoverable(throwable);

			String message = "Failed to resolve parameter [%s] in %s [%s]".formatted(parameterContext.getParameter(),
				asLabel(executable), executable.toGenericString());

			if (StringUtils.isNotBlank(throwable.getMessage())) {
				message += ": " + throwable.getMessage();
			}

			throw new ParameterResolutionException(message, throwable);
		}
	}

	private static void validateResolvedType(Parameter parameter, @Nullable Object value, Executable executable,
			ParameterResolver resolver) {

		Class<?> type = parameter.getType();

		// Note: null is permissible as a resolved value but only for non-primitive types.
		if (!isAssignableTo(value, type)) {
			String message;
			if (value == null && type.isPrimitive()) {
				message = """
						ParameterResolver [%s] resolved a null value for parameter [%s] \
						in %s [%s], but a primitive of type [%s] is required.""".formatted(
					resolver.getClass().getName(), parameter, asLabel(executable), executable.toGenericString(),
					type.getName());
			}

View on GitHub (pinned to f070c699a0)