我必须实现一些代码来遍历目录结构并返回找到的文件列表。要求非常简单：
- 给定一个基本目录，查找其中的所有文件（不是目录本身）。
- 如果找到目录，请重复步骤 1。
我想使用 TDD 开发代码。当我开始编写测试时，我意识到我在嘲笑班级File，这样我就可以拦截对File.isDirectory()等等。通过这种方式，我强迫自己使用一个可以调用该方法的解决方案。
我不喜欢它，因为这个测试肯定与实现紧密耦合。如果我改变了询问文件是否是目录的方式，那么即使我保持合约有效，这个测试也会失败。将其视为私人单元测试 http://theholyjava.wordpress.com/2011/10/20/never-mix-public-and-private-unit-tests/由于该帖子中表达的所有原因，让我感到不安。我不确定这是否是我需要使用此类测试的情况之一。另一方面，我真的想确保它返回每个不是目录的文件，遍历整个结构。对我来说，这需要一个好的、简单的测试。
我想避免必须在“磁盘上”创建带有真实测试文件的测试目录结构，因为我发现它相当笨拙并且违背了我读过的一些最佳实践。
请记住，我不需要对内容做任何事情，所以像使用这样的技巧StringReader代替FileReader不要在这里申请。不过，我认为我可以做一些等效的事情，比如在设置测试时能够在内存中创建一个目录结构，然后将其拆除。我还没有找到办法做到这一点。
您将如何使用 TDD 开发此代码？
Thanks!
你所犯的错误是嘲笑File。有一个测试反模式假设如果你的班级委托给班级X, you must模拟课X来测试你的班级。还有一条一般规则是在编写执行文件 I/O 的单元测试时要小心，因为它们往往太慢。但单元测试中并没有绝对禁止文件 I/O。
在单元测试中设置和拆除临时目录，并在该临时目录中创建测试文件和目录。是的，您的测试会比纯 CPU 测试慢，但它们仍然会很快。 JUnit 甚至有支持代码来帮助解决这种情况：@Rule on a TemporaryFolder.
就在本周，我使用 TDD 实现了一些必须扫描目录并删除文件的内务代码，所以我知道这是可行的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
