Source code
package org.junit.rules;
import org.junit.runner.Description;
import org.junit.runners.model.Statement;
/**
* A base class for Rules (like TemporaryFolder) that set up an external
* resource before a test (a file, socket, server, database connection, etc.),
* and guarantee to tear it down afterward:
*
* <pre>
* public static class UsesExternalResource {
* Server myServer= new Server();
*
* @Rule
* public ExternalResource resource= new ExternalResource() {
* @Override
* protected void before() throws Throwable {
* myServer.connect();
* };
*
* @Override
* protected void after() {
* myServer.disconnect();
* };
* };
*
* @Test
* public void testFoo() {
* new Client().run(myServer);
* }
* }
* </pre>
*
* @since 4.7
*/
public abstract class ExternalResource implements TestRule {
public Statement apply(Statement base, Description description) {
return statement(base);
}
private Statement statement(final Statement base) {
return new Statement() {
@Override
public void evaluate() throws Throwable {
before();
try {
base.evaluate();
} finally {
after();
}
}
};
}
/**
* Override to set up your specific external resource.
*
* @throws if setup fails (which will disable {@code after}
*/
protected void before() throws Throwable {
// do nothing
}
/**
* Override to tear down your specific external resource.
*/
protected void after() {
// do nothing
}
}
Run 1
The code is highly readable due to its clear structure, minimal nesting, and well-documented intent. The class follows a logical organization: the apply method delegates to a private statement method, which returns an anonymous Statement with a flat try-finally block. Action granularity is good, with one primary operation per line in the critical evaluate method. The reading flow is natural, aided by Javadoc examples and concise method names (before/after). While the anonymous inner class adds slight complexity, it is standard for JUnit rules and well-contained. Code length is appropriate, avoiding unnecessary verbosity while including essential documentation.
Run 2
The code is highly readable with a clear, logical structure. The class is well-organized, featuring a concise public API and a private helper method that encapsulates the try-finally logic to ensure proper resource cleanup. Nesting is minimal, with only one anonymous inner class and one try-finally block, both of which are common and necessary in JUnit rule implementations. Intent is clear through descriptive method names like 'before' and 'after' and concise Javadoc comments. The code length is appropriate, avoiding unnecessary verbosity while providing a complete example in the class-level Javadoc. Action granularity is excellent, with each statement on its own line and no hidden side-effects. Reading flow is natural: the public apply method leads directly to the private statement method, which contains the core execution logic. The only minor drawback is the slightly awkward 'statement(base)' return within apply, which could be simplified to return statement(base) directly.
Run 3
The code is well-structured with a clear separation of concerns: the apply method delegates to statement, which encapsulates the setup/teardown logic. Nesting is shallow, with only one anonymous inner class. Intent is explicit through meaningful method names (before, after, evaluate) and Javadoc examples. The code is concise, avoiding unnecessary boilerplate. Each logical action (before, try, evaluate, finally, after) is placed on its own line or block, improving readability. The reading flow is natural: apply -> statement -> evaluate, then before/after. Minor deductions: the Javadoc example contains a small formatting inconsistency and the @throws tag lacks a parameter description, but these do not significantly hinder comprehension.
Run 1
1. Code Structure: Well organized into rule application, statement wrapping, and lifecycle hooks; the private statement helper adds slight indirection. 2. Nesting: The anonymous class and try/finally introduce moderate but appropriate nesting. 3. Clarity of intent: Descriptive lifecycle names and documentation clearly communicate setup and teardown; the malformed @throws documentation slightly reduces clarity. 4. Code length: Implementation is concise, though the documentation example is relatively long and inconsistently formatted. 5. Action granularity: Each statement performs one clear action, with no crowded lines. 6. Reading flow: Execution reads naturally from before() through base.evaluate() to after(), and the finally block makes cleanup behavior easy to understand.
Run 2
Code Structure: Methods are logically organized, separating rule application, execution wrapping, setup, and teardown. Nesting: The anonymous Statement and try/finally introduce moderate but justified nesting. Clarity of intent: Descriptive lifecycle methods and documentation clearly communicate resource management, although the setup-failure Javadoc is malformed and the teardown guarantee could be qualified. Code length: The implementation is concise; the documentation example is useful but relatively lengthy, and the statement helper adds minor indirection. Action granularity: Each executable line performs a single clear action. Reading flow: Execution follows the natural before-test-after sequence, with finally making cleanup behavior easy to understand. Inconsistent formatting in the documentation example slightly reduces polish.
Run 3
Code Structure: Well-organized class with separate rule application, statement construction, and lifecycle hooks. Nesting: The anonymous class and try/finally introduce moderate but necessary nesting. Clarity of intent: Descriptive lifecycle names and documentation clearly explain resource setup and teardown; however, the setup-failure Javadoc is malformed, and teardown occurs only if before() succeeds. Code length: Concise implementation, though the statement() helper adds a small amount of indirection. Action granularity: Each statement performs one clear action. Reading flow: The implementation follows a natural setup-test-cleanup sequence, with hooks defined afterward. Inconsistent formatting in the documentation example slightly reduces polish.