Source code
package org.junit.experimental.categories;
import static java.util.Arrays.asList;
import static java.util.Collections.unmodifiableList;
import static java.util.Collections.unmodifiableSet;
import java.lang.annotation.Annotation;
import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.runners.model.FrameworkMethod;
import org.junit.validator.AnnotationValidator;
/**
* Validates that there are no errors in the use of the {@code Category}
* annotation. If there is, a {@code Throwable} object will be added to the list
* of errors.
*
* @since 4.12
*/
public final class CategoryValidator extends AnnotationValidator {
@SuppressWarnings("unchecked")
private static final Set<Class<? extends Annotation>> INCOMPATIBLE_ANNOTATIONS = unmodifiableSet(new HashSet<Class<? extends Annotation>>(
asList(BeforeClass.class, AfterClass.class, Before.class, After.class)));
/**
* Adds to {@code errors} a throwable for each problem detected. Looks for
* {@code BeforeClass}, {@code AfterClass}, {@code Before} and {@code After}
* annotations.
*
* @param method the method that is being validated
* @return A list of exceptions detected
*
* @since 4.12
*/
@Override
public List<Exception> validateAnnotatedMethod(FrameworkMethod method) {
List<Exception> errors = new ArrayList<Exception>();
Annotation[] annotations = method.getAnnotations();
for (Annotation annotation : annotations) {
for (Class<?> clazz : INCOMPATIBLE_ANNOTATIONS) {
if (annotation.annotationType().isAssignableFrom(clazz)) {
addErrorMessage(errors, clazz);
}
}
}
return unmodifiableList(errors);
}
private void addErrorMessage(List<Exception> errors, Class<?> clazz) {
String message = String.format("@%s can not be combined with @Category",
clazz.getSimpleName());
errors.add(new Exception(message));
}
}
Run 1
The code is well-structured and readable. It has a clear single responsibility (validating Category annotation usage), flat nesting (only two levels), and descriptive method/variable names. Imports are organized, and Javadoc explains the purpose. The logic flows naturally: collect annotations, check against incompatible annotations, accumulate errors, return them. The main weakness is the double nested loop with an `isAssignableFrom` check that could be slightly clearer, but it is still understandable. Lines are concise and one action per line is generally followed.
Run 2
The code is well-structured with clear separation of concerns: constants, validation logic, and error reporting. Nesting is minimal (two nested loops plus one conditional), maintaining flat logic. Intent is explicit — the class and method names clearly describe validation of @Category with incompatible annotations. Length is concise; the validator is focused and avoids unnecessary code. Each line generally performs one action, improving readability. Reading flow is natural: from annotation collection to compatibility check to error accumulation. Minor deductions: the isAssignableFrom logic could be clearer, and the @SuppressWarnings("unchecked") suggests a minor type-safety compromise in the constant definition. Overall, the code is highly readable and maintainable.
Run 3
The code is highly readable. It has a clear, single-purpose class with a well-named method and helper. Structure is logical: constant declaration, then public validation method, then private helper. Nesting is only two levels deep in the validation loop, which is acceptable. Intent is explicit through method names, Javadoc, and the descriptive INCOMPATIBLE_ANNOTATIONS constant. Length is concise and focused. Action granularity is good—each line performs one coherent operation. Reading flow is natural, moving from inputs to processing to output. Minor deduction is for the slightly confusing use of isAssignableFrom (semantic inversion) and the absence of a direct import for unmodifiableSet/List could be a style choice, but overall clarity is excellent.
Run 1
Code Structure: Clearly organized into an immutable annotation set, a validation method, and an error-message helper. Nesting: Two nested loops plus a conditional add moderate depth, but the short body remains easy to follow. Clarity of intent: Descriptive names and documentation explain the validation purpose, although clazz is generic and the documentation misleadingly mentions adding to an errors parameter. Code length: Concise overall, with some verbosity from generic types and the collection initializer. Action granularity: Statements generally perform one action per line; the initializer combines several operations. Reading flow: Imports, configuration, validation, and message construction appear in a natural order. The long initializer and assignability check require slightly more effort to interpret.
Run 2
Code Structure: Well organized, with a constant defining incompatible annotations, a validation method, and a focused error-message helper. Nesting: Two nested loops and an if statement add moderate depth, but the small body remains easy to follow. Clarity of intent: Descriptive names and documentation clearly communicate the validation purpose; the generic name clazz and isAssignableFrom check require some interpretation. Code length: Concise overall, though verbose generics and documentation add visual weight, and the documentation misleadingly refers to an errors parameter. Action granularity: Statements generally perform one action per line, except the dense collection initialization combining several calls. Reading flow: Imports, configuration, validation, and error construction follow a natural sequence, with the long constant declaration being the main interruption.
Run 3
Code Structure: Well organized, with incompatible annotations defined centrally, validation in one method, and error construction in a helper. Nesting: Two nested loops and a conditional create moderate nesting, but the short body remains easy to follow. Clarity of intent: Descriptive names and documentation communicate the purpose clearly, although isAssignableFrom requires some interpretation and the Javadoc inaccurately refers to adding to an errors parameter. Code length: Concise overall, with slightly verbose generic syntax and documentation. Action granularity: Statements generally perform one action each; the nested collection construction in the constant declaration is comparatively dense. Reading flow: Imports, configuration, validation, and error formatting follow a natural order, with the long constant declaration being the main visual interruption.