使用TDD开发Java中的文件遍历代码 [英] Using TDD to develop file traversing code in Java
问题描述
我必须实现一些代码来遍历目录结构并返回找到的文件列表.要求非常简单:
I had to implement some code to traverse a directory structure and return a list of files found. The requirements were pretty simple:
- 给出一个基本目录，找到其中的所有文件(不是目录本身).
- 如果找到目录，请对其重复步骤1.
我想使用TDD开发代码.当我开始编写测试时，我意识到我正在模拟类File，因此我可以拦截对File.isDirectory()的调用，依此类推.通过这种方式，我强迫自己使用一种可以调用该方法的解决方案.
I wanted to develop the code using TDD. As I started writing the tests, I realized that I was mocking class File, so I could intercept calls to File.isDirectory() and so on. In this way, I was forcing myself to use a solution where I would call that method.
我不喜欢它，因为该测试与实现紧密相关.如果我更改了询问文件是否为目录的方式，那么即使我保持合同有效，该测试也会失败.将其视为私有单元测试出于该帖子表达的所有原因，让我感到不安.我不确定这是否是我需要使用这种测试的情况之一.另一方面，我真的想确保它返回遍历整个结构的每个文件，而不是目录.对我来说，这需要一个很好的，简单的测试.
I didn't like it because this test is definitely tightly coupled to the implementation. If I ever change the way in which I ask if a file is a directory, then this test is going to fail even if I keep the contract working. Looking at it as a Private Unit Test made me feel uneasy, for all the reasons expressed on that post. I'm not sure if this is one of those cases where I need to use that kind of testing. On the other hand, I really want to be sure that it returns every file that its not also a directory, traversing the entire structure. To me, that requires a nice, simple, test.
我想避免不得不在磁盘上创建带有真实测试文件的测试目录结构，因为我发现它相当笨拙并且违反了我已阅读的一些最佳实践.
I wanted to avoid having to create a testing directory structure with real testing files "on disk", as I saw it rather clumsy and against some of the best practices that I have read.
请记住，我不需要对内容做任何事情，因此，使用StringReader代替FileReader的技巧在这里并不适用.我以为我可以做一些等效的事情，例如在设置测试时能够在内存中创建目录结构，然后将其拆除.我还没有找到一种方法.
Bear in mind that I don't need to do anything with the contents, so tricks like using StringReader instead of FileReader do not apply here. I thought I could do something equivalent, though, like being able to create a directory structure in memory when I set up the test, then tearing it down. I haven't found a way to do it.
您将如何使用TDD开发此代码?
How would you develop this code using TDD?
谢谢！
推荐答案
您犯的错误是模拟File.有一个测试反模式，它假定如果您的班级委派给类X，则您必须模拟类X来测试您的班级.还有一个一般规则，对于编写执行文件I/O的单元测试要谨慎，因为它们往往太慢.但是在单元测试中并没有绝对禁止文件I/O.
The mistake you have made is to mock File. There is a testing anti pattern that assumes that if your class delegates to class X, you must mock class X to test your class. There is also a general rule to be cautious of writing unit tests that do file I/O, because they tend to be too slow. But there is no absolute prohibition on file I/O in unit tests.
在您的单元测试中，建立并拆除了一个临时目录，并在该临时目录中创建测试文件和目录.是的，您的测试将比纯CPU测试慢，但仍会很快. JUnit甚至具有支持代码来帮助解决这种情况:在TemporaryFolder上的@Rule.
In your unit tests have a temporary directory set up and torn down, and create test files and directories within that temporary directory. Yes, your tests will be slower than pure CPU tests, but they will still be fast. JUnit even has support code to help with this very scenario: a @Rule on a TemporaryFolder.
就在本周，我使用TDD实现了一些内务处理代码，这些代码必须扫描目录并删除文件，所以我知道这可行.
Just this week I implemented, using TDD, some housekeeping code that had to scan through a directory and delete files, so I know this works.
这篇关于使用TDD开发Java中的文件遍历代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
