Source code
package org.junit.internal.builders;
import org.junit.runner.RunWith;
import org.junit.runner.Runner;
import org.junit.runners.model.InitializationError;
import org.junit.runners.model.RunnerBuilder;
public class AnnotatedBuilder extends RunnerBuilder {
private static final String CONSTRUCTOR_ERROR_FORMAT = "Custom runner class %s should have a public constructor with signature %s(Class testClass)";
private final RunnerBuilder fSuiteBuilder;
public AnnotatedBuilder(RunnerBuilder suiteBuilder) {
fSuiteBuilder = suiteBuilder;
}
@Override
public Runner runnerForClass(Class<?> testClass) throws Exception {
RunWith annotation = testClass.getAnnotation(RunWith.class);
if (annotation != null) {
return buildRunner(annotation.value(), testClass);
}
return null;
}
public Runner buildRunner(Class<? extends Runner> runnerClass,
Class<?> testClass) throws Exception {
try {
return runnerClass.getConstructor(Class.class).newInstance(testClass);
} catch (NoSuchMethodException e) {
try {
return runnerClass.getConstructor(Class.class,
RunnerBuilder.class).newInstance(testClass, fSuiteBuilder);
} catch (NoSuchMethodException e2) {
String simpleName = runnerClass.getSimpleName();
throw new InitializationError(String.format(
CONSTRUCTOR_ERROR_FORMAT, simpleName, simpleName));
}
}
}
}
Run 1
The code is well-structured and readable. It has a clear logical organization with a single public method entry point and a focused helper. Nesting is shallow, with only one nested try-catch inside the main try. Intent is clear: build a runner from the @RunWith annotation, falling back from a simple constructor to one accepting a RunnerBuilder. Action granularity is mostly one operation per line, though the constructor calls are somewhat dense. Naming is conventional and descriptive, though `fSuiteBuilder` uses an older prefix style. Minor deductions: the nested catch has duplicate logic and the constructor fallback could be refactored, but overall this is concise (< 30 lines of logic) and flows naturally from annotation detection to construction to error handling.
Run 2
The code is well-structured and readable. It follows a clear logical organization with a single purpose class. Nesting is limited to two levels within a try-catch, which is acceptable for the exception-handling logic. Intent is clear through descriptive method names like runnerForClass and buildRunner, and the error message constant contributes to clarity. Code length is concise, avoiding unnecessary verbosity. However, action granularity is somewhat mixed: the nested getConstructor/newInstance call combines multiple actions on one line, which slightly reduces readability. Overall reading flow is natural, progressing from annotation lookup to runner construction, with adequate exception handling. The main deductions come from the slightly dense constructor invocation lines and the moderate nesting in the catch block, but these are minor issues in an otherwise clean implementation.
Run 3
The code is well-structured with clear separation of concerns, minimal nesting (only two levels deep), and concise methods. Each line performs a single logical action, maintaining good action granularity. The use of a descriptive constant for the error message improves clarity. The reading flow is natural: annotation check, then builder invocation. The nested try-catch in buildRunner adds slight complexity but remains readable. Naming is clear except for 'fSuiteBuilder' (a legacy prefix), which is a minor issue. Overall, the code demonstrates high readability with only minor stylistic concerns.
Run 1
Code Structure: Well organized, separating annotation lookup from runner construction and centralizing the error message. Nesting: Mostly shallow, though nested try-catch blocks make constructor fallback slightly harder to follow. Clarity of intent: Method names, types, and the error message clearly communicate the purpose; fSuiteBuilder and generic exception names are less descriptive. Code length: Concise, with no unnecessary logic. Action granularity: Statements generally perform one action, although chained reflection calls combine constructor lookup and instantiation. Reading flow: Natural progression from annotation detection to preferred constructor, fallback constructor, and initialization error; line wrapping and nested exception handling introduce minor friction.
Run 2
Code Structure: Well organized, with annotation detection and runner construction separated into focused methods. Nesting: Mostly shallow, though nested try-catch blocks add complexity to constructor fallback handling. Clarity of intent: Method names, types, and the descriptive error message clearly communicate the purpose; fSuiteBuilder and generic exception names are slightly less expressive. Code length: Concise, with little unnecessary code. Action granularity: Statements generally perform one logical action, although chained reflection calls combine constructor lookup and instantiation. Reading flow: Natural progression from annotation lookup to preferred constructor, fallback constructor, and error reporting. Line wrapping slightly interrupts the reflection expressions but remains understandable.
Run 3
Code Structure: Well organized into annotation detection and runner construction, with a shared error-message constant. Nesting: Mostly shallow, though the nested try/catch adds complexity to constructor fallback handling. Clarity of intent: Descriptive method names and explicit constructor signatures make the purpose clear; fSuiteBuilder and generic exception names are slightly less intuitive. Code length: Concise, with no unnecessary logic or duplication. Action granularity: Statements generally perform one clear action, although reflection calls chain constructor lookup and instantiation. Reading flow: Natural progression from annotation lookup to preferred constructor, fallback constructor, and informative failure. Long lines and wrapped reflection calls slightly reduce scanning ease.