设计幂等的单元测试以安全验证文件操作行为，关键在于确保同一操作在多次执行时结果一致，不会因重复调用而产生副作用。以下是实现这一目标的步骤和最佳实践：1. 理解幂

本文介绍使用 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<Boolean> 或接口），便于在测试中控制；直接在方法内 throw new RuntimeException() 则需借助 try-catch + fail() 或 assertThrows 配合状态断言。

综上，@TempDir 是实现文件操作类方法幂等测试的简洁、健壮且符合测试最佳实践的方案——它用基础设施保障隔离性，让测试专注验证业务逻辑与副作用，而非管理测试残留。