Source code
package org.junit.rules;
import java.io.File;
import java.io.IOException;
import org.junit.Rule;
/**
* The TemporaryFolder Rule allows creation of files and folders that are
* guaranteed to be deleted when the test method finishes (whether it passes or
* fails):
*
* <pre>
* public static class HasTempFolder {
* @Rule
* public TemporaryFolder folder= new TemporaryFolder();
*
* @Test
* public void testUsingTempFolder() throws IOException {
* File createdFile= folder.newFile("myfile.txt");
* File createdFolder= folder.newFolder("subfolder");
* // ...
* }
* }
* </pre>
*
* @since 4.7
*/
public class TemporaryFolder extends ExternalResource {
private final File parentFolder;
private File folder;
public TemporaryFolder() {
this(null);
}
public TemporaryFolder(File parentFolder) {
this.parentFolder = parentFolder;
}
@Override
protected void before() throws Throwable {
create();
}
@Override
protected void after() {
delete();
}
// testing purposes only
/**
* for testing purposes only. Do not use.
*/
public void create() throws IOException {
folder = createTemporaryFolderIn(parentFolder);
}
/**
* Returns a new fresh file with the given name under the temporary folder.
*/
public File newFile(String fileName) throws IOException {
File file = new File(getRoot(), fileName);
if (!file.createNewFile()) {
throw new IOException(
"a file with the name \'" + fileName + "\' already exists in the test folder");
}
return file;
}
/**
* Returns a new fresh file with a random name under the temporary folder.
*/
public File newFile() throws IOException {
return File.createTempFile("junit", null, getRoot());
}
/**
* Returns a new fresh folder with the given name under the temporary
* folder.
*/
public File newFolder(String folder) throws IOException {
return newFolder(new String[]{folder});
}
/**
* Returns a new fresh folder with the given name(s) under the temporary
* folder.
*/
public File newFolder(String... folderNames) throws IOException {
File file = getRoot();
for (int i = 0; i < folderNames.length; i++) {
String folderName = folderNames[i];
file = new File(file, folderName);
if (!file.mkdir() && isLastElementInArray(i, folderNames)) {
throw new IOException(
"a folder with the name \'" + folderName + "\' already exists");
}
}
return file;
}
private boolean isLastElementInArray(int index, String[] array) {
return index == array.length - 1;
}
/**
* Returns a new fresh folder with a random name under the temporary folder.
*/
public File newFolder() throws IOException {
return createTemporaryFolderIn(getRoot());
}
private File createTemporaryFolderIn(File parentFolder) throws IOException {
File createdFolder = File.createTempFile("junit", "", parentFolder);
createdFolder.delete();
createdFolder.mkdir();
return createdFolder;
}
/**
* @return the location of this temporary folder.
*/
public File getRoot() {
if (folder == null) {
throw new IllegalStateException(
"the temporary folder has not yet been created");
}
return folder;
}
/**
* Delete all files and folders under the temporary folder. Usually not
* called directly, since it is automatically applied by the {@link Rule}
*/
public void delete() {
if (folder != null) {
recursiveDelete(folder);
}
}
private void recursiveDelete(File file) {
File[] files = file.listFiles();
if (files != null) {
for (File each : files) {
recursiveDelete(each);
}
}
file.delete();
}
}
Run 1
The code is well-structured and readable. It follows clear separation of concerns: public API methods, lifecycle overrides, and private helpers. Nesting is minimal, with only one conditional level in most methods. Intent is clearly conveyed through descriptive method names like 'newFile', 'newFolder', and 'recursiveDelete'. Code length is appropriate for the functionality provided. Action granularity is mostly one action per line, enhancing clarity. Reading flow is natural, with methods logically ordered: constructors, lifecycle methods, public API, then private utilities. Javadocs further clarify purpose and usage. Minor deducts: 'newFolder(String...)' has slight complexity due to loop logic, but still readable.
Run 2
The code is well-structured and readable. It has clear separation of concerns, with public API methods, lifecycle overrides, and private helpers. Nesting is minimal, mostly limited to simple conditionals and loops. Method names clearly express intent (e.g., `newFile`, `newFolder`, `recursiveDelete`). Code length is appropriate for the functionality; no unnecessary duplication exists. Each line generally performs one action, especially in methods like `createTemporaryFolderIn`. Reading flow is logical: constructors, lifecycle methods, public API, then private utilities. Javadoc is concise and helpful. Minor deductions: the `newFolder(String...)` loop slightly mixes index logic with file creation, and the `create()` method's comment placement is slightly awkward. Overall, this is clean, maintainable Java code.
Run 3
The code is well-structured and follows a clear, logical organization. Class responsibilities are separated cleanly, with public API methods grouped together and private helpers below. Nesting is minimal — the deepest indentation occurs in the newFolder and recursiveDelete methods, but it remains shallow and readable. Intent is clearly expressed through descriptive method names, Javadoc comments, and exception messages that explain failures in plain terms. The code is concise without sacrificing clarity; each method accomplishes one task and is appropriately sized. Action granularity is good: most lines perform a single operation, and loops are straightforward. Reading flow is natural, moving from setup/teardown methods to file creation utilities, then to cleanup helpers. Minor improvements could include extracting the inline conditional logic in newFolder slightly, but overall readability is very high.
Run 1
Code Structure: Well-organized class with focused methods separating lifecycle management, creation, access, and deletion. Nesting: Shallow overall; loops and conditionals introduce only modest nesting. Clarity of intent: Descriptive method names and Javadocs make the purpose clear, although the overloaded folder name and combined mkdir/last-element condition require extra attention. Code length: Mostly concise, with minor redundancy in comments and a small helper that adds navigation overhead. Action granularity: Generally one action per line; the conditional combining directory creation with an index check slightly obscures sequencing. Reading flow: Constructors, lifecycle hooks, creation methods, and cleanup follow a natural progression with consistent formatting. Minor distractions include unnecessary quote escaping and unchecked filesystem operations whose intended failure handling is unclear.
Run 2
Code Structure: Well-organized class with focused methods separating lifecycle management, creation, access, and deletion. Nesting: Mostly flat, with modest nesting in folder creation and recursive deletion. Clarity of intent: Descriptive names, documentation, and explicit exceptions make the purpose clear; the temporary-file-to-directory conversion and compound mkdir condition require closer reading. Code length: Methods are concise, though the last-element helper and repeated documentation add minor verbosity. Action granularity: Generally one action per line; the mkdir call inside a conditional mixes mutation with decision-making. Reading flow: Constructors and lifecycle hooks lead naturally into public operations and supporting helpers, with consistent formatting. Minor naming overlap between the folder field and a parameter slightly reduces clarity.
Run 3
Code Structure: Well organized into constructors, lifecycle hooks, creation methods, and cleanup helpers, with clear separation of responsibilities. Nesting: Generally shallow; recursive deletion has only a conditional and loop, while folder creation uses a loop with one conditional. Clarity of intent: Descriptive method names and Javadocs clearly communicate the temporary-folder lifecycle. Minor ambiguity comes from generic variables such as 'file' and 'folder', and the unexplained create-file/delete/mkdir technique. Code length: Methods are concise, although repetitive documentation and the trivial last-element helper add slight verbosity. Action granularity: Most statements perform one action; combining mkdir() with a last-element check in a condition slightly complicates interpretation. Reading flow: Consistent formatting and sensible method grouping make the class easy to follow, with only minor interruptions from overload delegation and helper lookups.