0

我正在开发一个模块，该模块提供导航目录和操作文件的方法。基本上它将是Dir和File类的组合，具有特定于我正在处理的项目需求的选项。

现在我已经开始为其中一些方法编写测试，事情变得一团糟。

例子

我拥有的方法之一是一个tree函数，它返回文件和文件夹的哈希值，您可以在其中传递tree(only: 'folders', limit: 3). 为了测试它只下降 3 个级别，我必须有 4 个以上的子文件夹，其中包含虚拟文件。

问题

现在我正在测试项目外部的文件夹，因为子文件夹已经存在，但我想摆脱这种情况，特别是考虑到一旦我开始测试等效于rm -rf的方法（以及缺乏可移植性）。

我开始认为我需要创建一个“实验室老鼠”类型的文件夹，我在上面进行所有“实验”，但我不知道如何创建它。

  • 我是否创建一个创建文件的函数？
  • 我是否从其他位置提取文件和文件夹？
  • 我是否对文件结构使用某种“lorem ipsum”生成器？
  • 我是否手动制作所有这些文件和文件夹（呃）？
  • 我是否只是模拟和存根所有内容而不实际创建/删除文件和文件夹？（我没有看到这种情况发生）

所以...

通常有人会如何测试过多的文件和文件夹操作？

4

1 回答 1

1

我认为您不想使用模拟/存根。您的操作系统的文件系统应该经过良好测试并且速度很快，因此模拟/存根的好处是微乎其微的。创建模拟/存根系统会增加复杂性而没有太多好处。

这是我的答案：

我是否创建一个创建文件的函数？
是的。您可以为这些函数创建测试以确保它们是正确的。不要调用Dirand File，而是编写使代码简单易读的辅助函数。也许您可以在源/测试代码之间共享帮助函数...

我是否从其他位置提取文件和文件夹？
不知道这是为了什么...

我是否对文件结构使用某种“lorem ipsum”生成器？
是的，如果您的意思是创建生成文件结构的函数。

我是否手动制作所有这些文件和文件夹（呃）？
不。

我是否只是模拟和存根所有内容而不实际创建/删除文件和文件夹？（我没有看到这种情况发生）
不。创建文件/目录的一个好处是您可以手动检查正在发生的事情而不是 100% 依赖于测试。这实际上是一个好方法，因为没有它可能会出现一个错误，即源代码和测试代码都没有按照您的预期执行，但您不会知道，因为一切似乎都在工作。

于 2012-10-28T02:48:49.580 回答