Source code
package org.junit.experimental.runners;
import java.lang.reflect.Modifier;
import java.util.ArrayList;
import java.util.List;
import org.junit.runners.Suite;
import org.junit.runners.model.RunnerBuilder;
/**
* If you put tests in inner classes, Ant, for example, won't find them. By running the outer class
* with Enclosed, the tests in the inner classes will be run. You might put tests in inner classes
* to group them for convenience or to share constants. Abstract inner classes are ignored.
* <p>
* So, for example:
* <pre>
* @RunWith(Enclosed.class)
* public class ListTests {
* ...useful shared stuff...
* public static class OneKindOfListTest {...}
* public static class AnotherKind {...}
* abstract public static class Ignored {...}
* }
* </pre>
*/
public class Enclosed extends Suite {
/**
* Only called reflectively. Do not use programmatically.
*/
public Enclosed(Class<?> klass, RunnerBuilder builder) throws Throwable {
super(builder, klass, filterAbstractClasses(klass.getClasses()));
}
private static Class<?>[] filterAbstractClasses(final Class<?>[] classes) {
final List<Class<?>> filteredList= new ArrayList<Class<?>>(classes.length);
for (final Class<?> clazz : classes) {
if (!Modifier.isAbstract(clazz.getModifiers())) {
filteredList.add(clazz);
}
}
return filteredList.toArray(new Class<?>[filteredList.size()]);
}
}
Run 1
The code is well-structured with a clear single responsibility: filtering abstract classes for a test suite. It has minimal nesting (one loop, one conditional), making the logic easy to follow. The Javadoc provides useful context and examples, enhancing clarity of intent. Method and variable names are descriptive ('filterAbstractClasses', 'filteredList', 'clazz'). The code is concise—no unnecessary lines or bloat. Action granularity is good; each line performs one logical operation. Reading flow is natural: class declaration, constructor, then helper method. Minor deductions: the single-line for loop with an if statement could be slightly more spacious, and the return statement packs multiple operations (toArray with array creation). Overall, this is highly readable Java code.
Run 2
The code is well-structured with clear separation between the public constructor and private helper method. Javadoc explains the purpose and usage of the class. Nesting is minimal, with only a single loop in the helper method. Intent is clear from method names and comments. Code length is concise. Most lines contain one action, though the filteredList initialization and method chaining slightly reduce granularity. Reading flow is natural due to logical ordering and descriptive names. Minor deductions: trailing whitespace after '}', and the comment about reflective use could be clearer.
Run 3
The code is highly readable with clear structure: a single class with two well-defined methods. Nesting is minimal—only one level in the loop with an early-continue style condition. Intent is explicit through the Javadoc example and method names like filterAbstractClasses. The code is concise, avoiding unnecessary abstractions. Each line performs one logical action, and the flow reads naturally: constructor delegates to filtering, then filter iterates and collects. Minor deductions include slightly inconsistent spacing in variable declarations and the use of a private method with a comment for reflection-only usage, which could be clearer with a static factory or clearer naming. Overall, it is self-documenting and idiomatic Java.
Run 1
Code Structure: The class is logically organized, with a minimal constructor delegating filtering to a focused helper. Nesting: A single loop containing one conditional keeps nesting shallow. Clarity of intent: Descriptive method names and useful documentation clearly explain the runner's purpose and exclusion of abstract classes; names such as klass and clazz are slightly less natural. Code length: The implementation is concise, and the longer documentation provides relevant context and an example. Action granularity: Each statement performs one clear action, with no crowded multi-statement lines. Reading flow: Documentation, constructor, and helper follow a natural progression. Minor spacing inconsistencies, particularly around the assignment operator, slightly reduce polish.
Run 2
Code Structure: Well organized, with a small constructor delegating filtering to a focused helper. Nesting: Shallow and easy to follow; only a loop containing one conditional. Clarity of intent: Descriptive class and method names, plus useful documentation and an example, clearly explain the runner's purpose and exclusion of abstract classes. Code length: Concise implementation with no unnecessary logic; documentation is longer but informative. Action granularity: Each statement performs a single clear action. Reading flow: Natural progression from documentation to constructor to filtering helper. Minor readability drawbacks include inconsistent spacing around the assignment operator and slightly generic variable names such as klass and clazz.
Run 3
Code Structure: The constructor delegates filtering to a focused helper, keeping responsibilities logically separated. Nesting: A single loop with one conditional creates only shallow nesting. Clarity of intent: Descriptive class and method names, explicit modifier checks, and useful documentation clearly explain the purpose; 'klass' and 'clazz' are slightly less natural variable names. Code length: The implementation is concise without unnecessary logic, and the longer documentation provides relevant context and an example. Action granularity: Each statement performs one clear action; the constructor's composed call remains easy to follow. Reading flow: The code progresses naturally from documented purpose to construction, filtering, and returning results. Minor spacing inconsistencies, such as the missing space before '=', slightly reduce polish.