Source code
package org.junit.runners.parameterized;
import static java.util.Collections.unmodifiableList;
import java.util.ArrayList;
import java.util.List;
import org.junit.runners.model.TestClass;
/**
* A {@code TestWithParameters} keeps the data together that are needed for
* creating a runner for a single data set of a parameterized test. It has a
* name, the test class and a list of parameters.
*
* @since 4.12
*/
public class TestWithParameters {
private final String fName;
private final TestClass fTestClass;
private final List<Object> fParameters;
public TestWithParameters(String name, TestClass testClass,
List<Object> parameters) {
notNull(name, "The name is missing.");
notNull(testClass, "The test class is missing.");
notNull(parameters, "The parameters are missing.");
fName = name;
fTestClass = testClass;
fParameters = unmodifiableList(new ArrayList<Object>(parameters));
}
public String getName() {
return fName;
}
public TestClass getTestClass() {
return fTestClass;
}
public List<Object> getParameters() {
return fParameters;
}
@Override
public int hashCode() {
int prime = 14747;
int result = prime + fName.hashCode();
result = prime * result + fTestClass.hashCode();
return prime * result + fParameters.hashCode();
}
@Override
public boolean equals(Object obj) {
if (this == obj) {
return true;
}
if (obj == null) {
return false;
}
if (getClass() != obj.getClass()) {
return false;
}
TestWithParameters other = (TestWithParameters) obj;
return fName.equals(other.fName)
&& fParameters.equals(other.fParameters)
&& fTestClass.equals(other.fTestClass);
}
@Override
public String toString() {
return fTestClass.getName() + " '" + fName + "' with parameters "
+ fParameters;
}
private static void notNull(Object value, String message) {
if (value == null) {
throw new NullPointerException(message);
}
}
}
Run 1
This code is highly readable due to its clear structure and logical organization. The class has a single responsibility, with fields, constructor, getters, and standard overrides well-separated. Nesting is minimal, limited to simple guard clauses in equals and notNull. Intent is clear from descriptive method names and consistent Javadoc-style comments. The code is concise, with no unnecessary duplication or verbose logic. Action granularity is good, with one main action per line in most methods. Reading flow follows a natural progression from fields to construction to accessors to overrides. Minor improvements could include using Objects.requireNonNull instead of a custom notNull method, and the hashCode implementation, while correct, uses an unusual prime constant that slightly obscures the standard pattern.
Run 2
The code is well-structured and highly readable. It follows a clear logical organization: fields, constructor, getters, equals/hashCode/toString, and a private helper. Nesting is minimal, with only simple null checks in equals and notNull. Intent is clear from descriptive names (fName, fTestClass, fParameters) and concise Javadoc. The code is appropriately concise and avoids unnecessary verbosity. Action granularity is good: the constructor performs null checks then assigns fields, and equals uses early returns for readability. Reading flow is natural, with methods arranged in a conventional order. Minor deductions: the deprecated field prefix 'f' is slightly dated, and the hashCode prime constant could be more descriptive, but these are trivial. Overall, this is exemplary, maintainable Java code.
Run 3
The code is highly readable with clear structure and intent. It follows a logical organization: fields, constructor, getters, then standard methods (hashCode, equals, toString), and a helper. Nesting is minimal—the only nested blocks are simple null checks and equals comparisons. Each method has a single, obvious purpose, and actions are well granularized. Variable names are descriptive (though f-prefix is slightly dated), and the constructor defensively copies and validates inputs. The equals/hashCode implementations are straightforward and correct. Minor deductions: the line-wrapping in equals slightly interrupts flow, and 'notNull' could be a reusable utility rather than private. Overall this is clean, maintainable, production-quality code.
Run 1
Code Structure: Clearly organized into fields, construction, getters, standard overrides, and a validation helper. Nesting: Minimal; guard clauses keep equals flat and easy to follow. Clarity of intent: Class documentation, descriptive method names, and explicit validation messages explain its purpose well. The f-prefixed fields and unexplained hash multiplier are minor distractions. Code length: Concise for a value-object class, with little unnecessary code. Action granularity: Statements generally perform one action per line; the defensive copy and unmodifiable wrapper combine related operations clearly. Reading flow: Consistent formatting and conventional method ordering make the class straightforward to read.
Run 2
Code Structure: Logically organized into fields, constructor, accessors, standard overrides, and a validation helper. Nesting: Minimal; guard clauses keep equals flat and easy to follow. Clarity of intent: Documentation, descriptive method names, and explicit validation make the immutable data container's purpose clear. The f-prefixed fields and unexplained hash prime slightly reduce clarity. Code length: Concise, with little unnecessary code; accessor and equality boilerplate is appropriate. Action granularity: Each statement performs one clear action, while wrapped expressions remain readable. Reading flow: Consistent formatting and conventional method ordering support a natural top-to-bottom reading flow.
Run 3
Code Structure: Well-organized value object with fields, constructor, accessors, standard overrides, and a validation helper. Nesting: Minimal; guard clauses keep equals flat, and conditionals are shallow. Clarity of intent: Documentation, descriptive method names, and explicit validation make the purpose clear. The f-prefixed fields and unexplained hash prime are minor distractions. Code length: Concise for its responsibilities, with little unnecessary code. Action granularity: Statements generally perform one action per line; the defensive-copy expression combines related operations clearly. Reading flow: Natural progression from initialization to access and object behavior, supported by consistent formatting and spacing.