Source code
package org.junit.rules;
import org.junit.runner.Description;
/**
* The TestName Rule makes the current test name available inside test methods:
*
* <pre>
* public class TestNameTest {
* @Rule
* public TestName name= new TestName();
*
* @Test
* public void testA() {
* assertEquals("testA", name.getMethodName());
* }
*
* @Test
* public void testB() {
* assertEquals("testB", name.getMethodName());
* }
* }
* </pre>
*
* @since 4.7
*/
public class TestName extends TestWatcher {
private String fName;
@Override
protected void starting(Description d) {
fName = d.getMethodName();
}
/**
* @return the name of the currently-running test method
*/
public String getMethodName() {
return fName;
}
}
Run 1
The code is highly readable. It has a clear structure, with a focused class, a well-documented Javadoc example, and minimal nesting. The class extends TestWatcher, making its purpose obvious. There is no unnecessary nesting or complexity. The method starting() is concise and performs a single assignment. The getter is trivial and clear. Field naming (fName) is slightly dated but understandable. Overall, the code follows clean code principles, with a good balance of documentation and simplicity.
Run 2
The code is highly readable. It has a clear, logical structure with a single class extending TestWatcher, minimal methods, and flat nesting. The Javadoc example effectively demonstrates usage, enhancing clarity of intent. Method and field names are descriptive, except for the minor legacy-style 'fName' prefix. The code is concise, with one action per line, and the reading flow is natural: documentation, field declaration, lifecycle override, then accessor. Minor deductions are for the unconventional field naming and the slight verbosity of the Javadoc example, but overall it is exemplary.
Run 3
The code is highly readable. It has a clear structure with a single class, minimal but appropriate field, and two straightforward methods. Nesting is completely flat. The intent of the TestName rule is obvious from the class name, method names, and Javadoc example, which uses a simple, illustrative code snippet. Code length is concise and avoids unnecessary complexity. Each line performs a distinct action (assigning the method name, returning it). The reading flow follows a logical order: class declaration, field, lifecycle override, public accessor. The only minor deductions are the slightly dated naming convention (fName) and the Javadoc example using an older JUnit import style, but overall readability is excellent.
Run 1
Code Structure: Clearly organized into a field, lifecycle callback, and getter. Nesting: Minimal, with no conditional or loop nesting. Clarity of intent: The class name, method names, and documentation clearly explain its purpose; fName and d are slightly less descriptive than ideal. Code length: The implementation is concise, and the longer documentation provides a useful usage example. Action granularity: Each executable statement performs one action on its own line. Reading flow: Natural progression from usage documentation to state, initialization callback, and accessor. Minor formatting inconsistencies in the documentation example slightly reduce polish.
Run 2
Code Structure: Logically organized into a single-purpose class with one field, a lifecycle callback, and an accessor. Nesting: Flat, with no conditional or loop nesting. Clarity of intent: Class documentation, the usage example, and method names clearly explain the purpose; abbreviated names fName and d slightly reduce clarity. Code length: Implementation is concise, and the longer documentation provides useful context rather than unnecessary complexity. Action granularity: Each statement performs one simple action. Reading flow: Natural progression from documentation to state, state initialization, and retrieval; minor formatting inconsistencies in the example are the only notable distraction.
Run 3
Code Structure: Logically organized into a single-purpose class, private field, lifecycle override, and accessor. Nesting: Flat, with no nested control flow. Clarity of intent: The class documentation, usage example, and method names clearly explain its purpose; abbreviated names fName and d are slightly less descriptive. Code length: The implementation is minimal, and the longer documentation provides useful context. Action granularity: Each statement performs one action. Reading flow: Natural progression from documentation to state, initialization, and retrieval, with minor formatting inconsistencies in the example.