Source code
package junit.framework;
import java.util.List;
import org.junit.Ignore;
import org.junit.runner.Describable;
import org.junit.runner.Description;
import org.junit.runner.Request;
import org.junit.runner.Runner;
import org.junit.runner.manipulation.Filter;
import org.junit.runner.manipulation.Filterable;
import org.junit.runner.manipulation.NoTestsRemainException;
import org.junit.runner.manipulation.Sortable;
import org.junit.runner.manipulation.Sorter;
public class JUnit4TestAdapter implements Test, Filterable, Sortable, Describable {
private final Class<?> fNewTestClass;
private final Runner fRunner;
private final JUnit4TestAdapterCache fCache;
public JUnit4TestAdapter(Class<?> newTestClass) {
this(newTestClass, JUnit4TestAdapterCache.getDefault());
}
public JUnit4TestAdapter(final Class<?> newTestClass, JUnit4TestAdapterCache cache) {
fCache = cache;
fNewTestClass = newTestClass;
fRunner = Request.classWithoutSuiteMethod(newTestClass).getRunner();
}
public int countTestCases() {
return fRunner.testCount();
}
public void run(TestResult result) {
fRunner.run(fCache.getNotifier(result, this));
}
// reflective interface for Eclipse
public List<Test> getTests() {
return fCache.asTestList(getDescription());
}
// reflective interface for Eclipse
public Class<?> getTestClass() {
return fNewTestClass;
}
public Description getDescription() {
Description description = fRunner.getDescription();
return removeIgnored(description);
}
private Description removeIgnored(Description description) {
if (isIgnored(description)) {
return Description.EMPTY;
}
Description result = description.childlessCopy();
for (Description each : description.getChildren()) {
Description child = removeIgnored(each);
if (!child.isEmpty()) {
result.addChild(child);
}
}
return result;
}
private boolean isIgnored(Description description) {
return description.getAnnotation(Ignore.class) != null;
}
@Override
public String toString() {
return fNewTestClass.getName();
}
public void filter(Filter filter) throws NoTestsRemainException {
filter.apply(fRunner);
}
public void sort(Sorter sorter) {
sorter.apply(fRunner);
}
}
Run 1
The code is well-structured with clear separation of concerns and sensible method ordering. Nesting is minimal, with only one level in the removeIgnored loop. Intent is generally clear from method names and the use of the JUnit framework abstractions. The class is concise for what it does; there's no obvious bloat. Actions are mostly granular, one per line, and the reading flow progresses logically from construction through behavior to reflective helpers. The main readability weaknesses are the slightly cryptic field names prefixed with 'f', and the private helper methods appear after their use, which is acceptable but not ideal. Overall, it is easy to follow.
Run 2
The code demonstrates excellent readability through clear structure, consistent naming conventions, and logical organization. The class follows a cohesive adapter pattern with well-separated methods. Nesting is minimal with only one level in the removeIgnored method's loop. Each method has a single clear purpose, proven by descriptive names like removeIgnored, isIgnored, and getTestClass. Field names use 'f' prefix consistently (fRunner, fCache, fNewTestClass), aiding identification of instance variables. Comments appropriately explain Eclipse-specific reflective interfaces. The removeIgnored method is particularly well-written—it recursively filters ignored tests logically and readably. Code length is concise; no method exceeds necessary length. Action granularity maintains one action per line without excessive fragmentation. Reading flow follows natural progression from construction to behavior to utility methods. Minor deductions: the dual constructor delegation could confuse some readers, and the reflective interface comments are slightly mysterious without context, but overall this is production-quality readable code.
Run 3
The code is well-structured and readable. It follows a clean class organization with clear separation of concerns (adapter pattern). Methods are focused and concise, each performing a single responsibility. Naming is descriptive and follows Java conventions. The nesting level is minimal, with only a single level in the recursive `removeIgnored` method and the loop within it. Reading flow is natural, progressing from construction to count, run, reflective accessors, and description filtering. The recursive helper method `removeIgnored` and `isIgnored` are clear in intent and keep complexity localized. One minor readability consideration is the use of Java's older 'f' prefix for fields, which some may find less modern, but it's a common JUnit convention and consistent throughout. Overall, the code is highly readable.
Run 1
Code Structure: Fields, constructors, and small, focused methods are logically organized, with delegation clearly separated from recursive description processing. Nesting: Mostly flat; removeIgnored uses only a loop with one nested conditional and an early return. Clarity of intent: Method names communicate purpose well, although legacy f-prefixed fields and the generic variable each are less descriptive. Code length: Concise, with little redundancy or unnecessary boilerplate. Action granularity: Statements generally perform one action per line; chained calls are short and understandable. Reading flow: Consistent formatting and straightforward delegation make the class easy to follow. The recursive filtering method is readable, though a brief explanation of ignored-node handling and consistent @Override annotations would improve clarity.
Run 2
Code Structure: Fields, constructors, and focused methods are logically organized, with runner delegation separated from description filtering. Nesting: Mostly flat; removeIgnored uses only a loop with one nested conditional and a clear early return. Clarity of intent: Method names and delegation make the adapter's purpose clear, though legacy f-prefixed fields and generic names such as each slightly reduce expressiveness. Code length: Concise, with little duplication or unnecessary logic. Action granularity: Each statement performs one clear action, and intermediate variables make recursive filtering easy to follow. Reading flow: Consistent formatting and short methods support natural reading; the recursive helper is straightforward. Minor weaknesses include missing @Override annotations on implemented interface methods and comments that provide limited context.
Run 3
Code Structure: Well-organized adapter with focused methods and clearly separated responsibilities. Nesting: Mostly flat; the recursive ignore-removal method has only a loop and a nested conditional, remaining easy to follow. Clarity of intent: Descriptive method names and straightforward delegation make the purpose clear, though legacy f-prefixed fields and the generic variable name 'each' slightly reduce clarity. Code length: Concise, with little unnecessary code; short forwarding methods suit the adapter pattern. Action granularity: Statements generally perform one action per line, and intermediate variables clarify recursive processing. Reading flow: Constructors, accessors, description processing, and runner operations follow a sensible sequence. Consistent formatting supports scanning, although grouping filter and sort with other runner operations and consistently adding @Override annotations would improve navigation.