Source code
package org.junit.runner.manipulation;
import org.junit.runner.Description;
import org.junit.runner.Request;
/**
* The canonical case of filtering is when you want to run a single test method in a class. Rather
* than introduce runner API just for that one case, JUnit provides a general filtering mechanism.
* If you want to filter the tests to be run, extend <code>Filter</code> and apply an instance of
* your filter to the {@link org.junit.runner.Request} before running it (see
* {@link org.junit.runner.JUnitCore#run(Request)}. Alternatively, apply a <code>Filter</code> to
* a {@link org.junit.runner.Runner} before running tests (for example, in conjunction with
* {@link org.junit.runner.RunWith}.
*
* @since 4.0
*/
public abstract class Filter {
/**
* A null <code>Filter</code> that passes all tests through.
*/
public static final Filter ALL = new Filter() {
@Override
public boolean shouldRun(Description description) {
return true;
}
@Override
public String describe() {
return "all tests";
}
@Override
public void apply(Object child) throws NoTestsRemainException {
// do nothing
}
@Override
public Filter intersect(Filter second) {
return second;
}
};
/**
* Returns a {@code Filter} that only runs the single method described by
* {@code desiredDescription}
*/
public static Filter matchMethodDescription(final Description desiredDescription) {
return new Filter() {
@Override
public boolean shouldRun(Description description) {
if (description.isTest()) {
return desiredDescription.equals(description);
}
// explicitly check if any children want to run
for (Description each : description.getChildren()) {
if (shouldRun(each)) {
return true;
}
}
return false;
}
@Override
public String describe() {
return String.format("Method %s", desiredDescription.getDisplayName());
}
};
}
/**
* @param description the description of the test to be run
* @return <code>true</code> if the test should be run
*/
public abstract boolean shouldRun(Description description);
/**
* Returns a textual description of this Filter
*
* @return a textual description of this Filter
*/
public abstract String describe();
/**
* Invoke with a {@link org.junit.runner.Runner} to cause all tests it intends to run
* to first be checked with the filter. Only those that pass the filter will be run.
*
* @param child the runner to be filtered by the receiver
* @throws NoTestsRemainException if the receiver removes all tests
*/
public void apply(Object child) throws NoTestsRemainException {
if (!(child instanceof Filterable)) {
return;
}
Filterable filterable = (Filterable) child;
filterable.filter(this);
}
/**
* Returns a new Filter that accepts the intersection of the tests accepted
* by this Filter and {@code second}
*/
public Filter intersect(final Filter second) {
if (second == this || second == ALL) {
return this;
}
final Filter first = this;
return new Filter() {
@Override
public boolean shouldRun(Description description) {
return first.shouldRun(description)
&& second.shouldRun(description);
}
@Override
public String describe() {
return first.describe() + " and " + second.describe();
}
};
}
}
Run 1
The code is well-structured and readable. It has a clear package and imports, comprehensive Javadocs explaining intent, and logical separation of methods. Nesting is minimal, with at most one level in `shouldRun` and `intersect`. The `ALL` constant and `matchMethodDescription` factory are concise and self-explanatory. Action granularity is good—each line performs one logical step. Reading flow is natural, with abstract methods grouped first, followed by concrete implementations. The only minor issues are a slight inconsistency in Javadoc formatting (the first paragraph of class Javadoc is a single block) and the `apply` method's parameter name `child` could be more descriptive, but these do not significantly affect readability.
Run 2
The code is well-structured with clear separation of concerns: the abstract Filter class defines a clean interface, and the static ALL and matchMethodDescription filters are concise. Javadoc comments are thorough and explain the purpose of each method and field. The nested anonymous classes are appropriate for the pattern and not overly deep. The main readability issue is the intersect method's anonymous class, which introduces some complexity with two filter references (first and second). The apply method does type checking and casting, which is slightly awkward but standard for this design. Overall, the code is readable with good naming, flat structure, and clear intent, but the anonymous inner classes and type cast add minor friction.
Run 3
The code is well-structured with clear separation of methods and logical organization. Nesting is minimal, with only one level inside matchMethodDescription's shouldRun method. Each method has a clear purpose: shouldRun, describe, apply, and intersect. The Javadoc comments enhance clarity of intent. The code is concise without being excessively brief. Each line performs a single action consistently. The reading flow is natural, with the class constants first, followed by static factory methods, then core abstract methods, and finally concrete helper methods. Minor deductions: some methods like apply() could be slightly more explicit in explaining object casting, and the overall length is moderate but appropriate for a filter abstraction.
Run 1
Code Structure: Logically organized around a clear filtering abstraction, with related factory methods and operations grouped coherently. Nesting: Generally shallow; anonymous classes and the recursive child traversal add moderate nesting without becoming tangled. Clarity of intent: Descriptive method names, straightforward conditions, and useful Javadoc make behavior clear, though calling ALL a 'null Filter' is potentially confusing. Code length: Implementation is concise; anonymous-class boilerplate and some repetitive documentation slightly increase length. Action granularity: Statements generally perform one action per line, and compound boolean expressions remain easy to understand. Reading flow: Consistent formatting, early returns, and small methods support natural reading, with minor interruptions from verbose documentation and anonymous implementations.
Run 2
Code Structure: Logically organized into a default filter, a factory method, abstract contracts, and application/composition methods. Nesting: Generally shallow; anonymous classes and the recursive child traversal introduce moderate nesting without becoming tangled. Clarity of intent: Descriptive method names and Javadoc clearly explain filtering behavior, although calling ALL a 'null Filter' and naming a runner parameter 'child' are slightly confusing. Code length: Implementations are concise; documentation adds useful context, with minor redundancy. Action granularity: Statements generally perform one action per line, and the split conjunction remains easy to follow. Reading flow: Consistent formatting, early returns, and straightforward control flow support natural reading. Anonymous implementations add some visual overhead, and minor Javadoc punctuation issues slightly reduce polish.
Run 3
Code Structure: Well-organized abstraction with distinct methods for matching, applying, and intersecting filters. Nesting: Mostly shallow; anonymous classes and the recursive child traversal introduce moderate nesting but remain manageable. Clarity of intent: Descriptive method names, straightforward conditions, and useful Javadoc make the filtering behavior clear. Minor drawbacks include generic names such as 'each' and 'child', and describing ALL as a 'null Filter'. Code length: Appropriately concise implementation, although some documentation is repetitive and anonymous-class boilerplate adds length. Action granularity: Statements generally perform one action per line; compound boolean expressions remain easy to understand. Reading flow: Consistent formatting, early returns, and logical method grouping support natural reading. Minor Javadoc punctuation issues and extra blank lines slightly reduce polish.