java - 在基于 TDD 的单元测试中处理 I/O

Question

我正在练习基于 Java 的 TDD 并编写了一些代码，用于读取和写入文件。现在，我对每个场景(读取和写入)进行了大约 100 个测试来测试我的代码，我每次都在其中创建文件或读取给定文件。要写入的文件将在临时目录中创建，并在每次测试运行后删除。但是这种策略会产生大量的 I/O，我担心例如固态硬盘生命周期。模拟不是一种选择。

一种可能性是读/写文件一次，然后针对(静态)数据结构(伪代码)运行我的测试:

private static Object resultData = null;

@BeforeClass
// Read/Write my stuff here
resultData = ....

@Test
// Check my requirements
assertTrue(resultData....);

问题是，我可以在测试方法中改变预期的行为，所以我的测试不再是自主的。

你会如何处理？

Answer 1

But this strategy produces a lot of I/O and I'm afraid in case of e.g. SSD lifetime.

你想太多了:对于 SSD Disk，DWPD(驱动器每天写入次数)为 1 (这在今天已经足够标准了)适用于许多用例。
DWPD 测量您在一天的生命周期内可以覆盖驱动器的整个大小的次数。
对于 500 个 GO 磁盘，DWPD 为 1 意味着理论上您可以每天写入 500 个 GO，而未达到产品保修政策期限。
这通常在 5 到 10 年之间。
因此，如果您每天执行数百万次构建，则在每次构建(100 个或更多)时创建的一些临时文件几乎什么都不是。

此外，您不应该因为这种考虑而使代码或测试变得更复杂。
SSD 的存在是为了让开发人员的事情变得更简单，而不是更复杂。

话虽这么说，但在单元测试中避免写入如此多的文件仍然有意义，因为必须快速执行测试。
您可以更改测试类的 API，使其也接受 ByteArrayInputStream 和 ByteArrayOutputStream。通过这种方式，读写将在内存中进行，而不是在文件系统中进行。