听说测试中访问数据库是错误的。
但是文件操作呢？ FileUtils 中的 cp、mv、rm 和 touch 方法。
如果我编写一个测试并实际运行命令（移动文件、重命名文件、创建目录等），我可以测试它们。但是我需要在再次运行测试之前“撤消”我运行的每个命令。所以我决定把所有的代码都写成“撤消”，但这似乎是在浪费时间，因为我真的不需要“撤消”。
我真的很想看看别人是怎么做的。例如，当您生成大量静态文件时，您将如何测试？
【问题讨论】：
标签： ruby unit-testing file testing
在您的情况下，访问文件是完全合法的，如果您正在编写文件操作代码，则应在文件上进行测试。您必须注意的一件事是，失败的测试意味着您的代码是错误的，而不是有人删除了测试所需的文件或类似的东西。我会将测试所需的目录和文件放在一个单独的文件夹中，该文件夹仅用于测试。然后在测试的构建中将整个文件夹复制到一个临时位置进行所有测试，然后在测试后删除临时文件。这样，每个测试都有一个为测试保存的文件的干净副本。
【讨论】：
“纯”单元测试应not access "expensive" resources如文件系统、数据库...
现在您可能希望在进行单元测试的同时运行那些“集成”测试（或任何您称之为的测试），并使用方便的相同框架。
您可以按照 Janusz 的回答中的建议将一组用于单元测试的文件复制到临时位置，或者在单元测试中生成它们，或者您可以在单元测试时使用 mock of the FileUtils 而不是真正的 FileUtils .
【讨论】：
访问数据库并不是“测试错误”。您还将如何测试代码与数据库的集成？
可重复测试的关键是一致的环境。只要您从相同的文件系统或数据库内容开始进行测试，就不会错。这通常通过测试套件开始时的清理过程来处理。
【讨论】：
访问数据库、文件系统、smtp 服务器等资源对于单元测试来说是个坏主意。在某些时候显然你必须用真实的文件来尝试它，这是一种不同的测试，一个集成测试。集成测试更痛苦，你必须小心确保你的测试是从一个明确定义的状态开始的，而且由于你正在访问真实的文件系统，它们会运行得更慢。另一方面，您不必像单元测试那样频繁地运行它们。
对于单元测试，您应该能够利用鸭子类型来创建对象，这些对象对您正在使用的文件对象所具有的相同方法做出反应。此外，这种方法无需撤消任何操作，并且测试运行速度会更快。
【讨论】：
如果您的操作系统支持基于 RAM 的文件系统，您可以选择其中之一。这甚至有一个优势，即代码中偶尔出现的`unix command` 可以继续工作。
【讨论】：
也许您可以在测试包中创建一个名为“test_*”的目录。然后，您更改的文件将放在此目录中（例如：如果您创建一个目录，您将在 test 目录中创建该目录）。在测试结束时，您可以删除此目录（仅使用一个命令）。这是您将执行的唯一 UNDO 操作。
您会将测试所需的所有文件放在测试包内的测试目录中。
【讨论】：