如何测试文件操作

Question

我听说在测试中访问数据库是错误的。

但是文件操作呢？类似于FileUtils中的cp，mv，rm和touch方法。

如果我编写测试并实际运行命令（移动文件，重命名文件，制作目录等），我可以测试它们。但是我需要在再次运行测试之前“撤消”我运行的每个命令。所以我决定将所有代码写成“撤消”，但这似乎是浪费时间，因为我真的不需要“撤消”。

我真的很想看别人怎么做。例如，当您生成大量静态文件时，您将如何测试？

Answer 1

“纯”单元测试应not access "expensive" resources，例如filesystem，DB ......

现在，您可能希望在单元测试的同时运行这些“集成”测试（或任何您称之为的测试），并使用相同的框架。

您可以拥有一组用于单元测试的文件，您可以按照Janusz的回答中的建议将其复制到临时位置，或者在单元测试中生成它们，或者您可以使用mock of the FileUtils而不是真正的FileUtils单元测试。

Answer 2

在你的情况下访问文件是完全合法的，如果你正在编写文件操作代码，它应该在文件上进行测试。您必须要注意的一件事是，测试失败意味着您的代码是错误的，而不是某人删除了测试所需的文件或类似的东西。我会将测试所需的目录和文件放在一个仅用于测试的单独文件夹中。然后在构建测试副本的整个文件夹到临时的地方做所有测试，然后在测试后删除临时文件。这样，每个测试都有一个为测试保存的文件的干净副本。

Answer 3

访问数据库，文件系统，smtp服务器等资源是单元测试的坏主意。在某些时候，显然你必须要用真实的文件来尝试，这是一种不同的测试，一种集成测试。集成测试更加痛苦，您必须注意确保测试从定义良好的状态开始，并且在访问真实文件系统时它们也会运行得更慢。另一方面，您不必像使用单元测试那样频繁地运行它们。

对于单元测试，您应该能够利用duck typing来创建对与您正在使用的文件对象相同的方法做出反应的对象。此外，这种方法无需撤消，测试运行速度会快得多。

Answer 4

访问数据库不是“测试中的错误”。您还将如何测试代码与数据库的集成？

可重复测试的关键是一致的环境。只要你从相同的文件系统或数据库内容开始测试，你应该没有错。这通常通过测试套件开始时的清理过程来处理。

Answer 5

如果您的操作系统支持基于RAM的文件系统，则可以使用其中一种。这甚至具有以下优点：代码中偶尔会`unix command`继续工作。

Answer 6

也许您可以在名为“test_ *”的测试包中创建一个目录。然后，您更改的文件将放在此目录中（例如：如果您创建目录，则将在test目录中创建该目录）。在测试结束时，您可以删除此目录（只有一个命令）。这是您将执行的唯一UNDO操作。

您将测试所需的所有文件放在测试包中的测试目录中。