本文介绍使用 junit 5 的 `@tempdir` 注解创建隔离、自动清理的临时测试目录，实现对 `loadfile()` 方法的幂等单元测试，确保每次运行结果一致，并可靠验证 `files.move()` 和 `files.delete()` 的调用效果。
在测试涉及真实文件系统操作（如删除或重命名）的方法时，一个常见痛点是测试不幂等：首次执行可能成功删除文件，第二次再运行则因文件不存在而失败；若异常路径触发重命名，后续测试又会因文件名变更而断言失败。这不仅破坏测试的可重复性，也违背单元测试“快速、独立、可靠”的基本原则。
解决该问题的核心思路是：为每次测试提供全新、隔离、生命周期受控的文件环境。JUnit 5.4+ 提供的 @TempDir 参数化注解正是为此而生——它会在测试方法执行前自动创建一个唯一的临时目录，并在测试结束后（无论成功或失败）递归清理其中所有内容，包括子目录和文件。这意味着每个测试用例都拥有专属“沙箱”，彼此零干扰。
以下为推荐的测试实现：
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.io.TempDir;
import java.nio.file.Files;
import java.nio.file.Path;
import static org.junit.jupiter.api.Assertions.*;
@Test
void loadsFileCorrectly(@TempDir Path temp) throws Exception {
Path file = temp.resolve("data.txt");
Files.createFile(file); // 准备输入文件
loadFile(file); // 执行被测方法（正常路径）
assertTrue(Files.notExists(file)); // 验证文件已被删除
}
@Test
void loadsFileWithException(@TempDir Path temp) throws Exception {
Path file = temp.resolve("corrupt.dat");
Files.createFile(file);
// 模拟方法内部抛出 RuntimeException（例如通过 Mockito mock 依赖，或注入故障触发器）
// 此处假设已配置好异常场景（见下方说明）
loadFile(file);
Path errorPath = file.resolveSibling("ERROR_" + file.getFileName());
assertTrue(Files.exists(errorPath)); // 验证重命名成功
assertFalse(Files.exists(file)); // 原文件不应存在
}⚠️ 关键注意事项：
- @TempDir 仅适用于 JUnit 5.4 及以上版本，请确保 junit-jupiter 依赖版本 ≥ 5.4.1；
- 测试中必须显式创建待测文件（如 Files.createFile(file)），因为 @TempDir 只创建空目录；
- 要验证 Files.move() 和 Files.delete() 的实际调用行为，上述断言已足够（检查文件系统状态变化），无需 mock Files 类本身（因其是 final 类，mock 成本高且削弱测试真实性）；
- 若需精确验证异常路径，建议将 RuntimeException 的触发逻辑抽离为可注入的策略（如 Supplier
或接口），便于在测试中控制；直接在方法内 throw new RuntimeException() 则需借助 try-catch + fail() 或 assertThrows 配合状态断言。
综上，@TempDir 是实现文件操作类方法幂等测试的简洁、健壮且符合测试最佳实践的方案——它用基础设施保障隔离性，让测试专注验证业务逻辑与副作用，而非管理测试残留。
