I had to implement some code to traverse a directory structure and return a list of files found. The requirements were pretty simple:
As someone who gets very antsy about unit tests that take longer than a few milliseconds to complete, I strongly recommend mocking out the file I/O.
However, I don't think you should mock the File
class directly. Instead, look at your use of the File
class as the "how", and try to identify the "what". Then codify that with an interface.
For example: you mentioned that one of the things you do is intercept calls to File.isDirectory
. Instead of interacting with the File
class, what if your code interacted with some implementation of an interface like:
public interface FileSystemNavigator {
public boolean isDirectory(String path);
// ... other relevant methods
}
This hides the use of File.isDirectory
from the rest of your code, while simultaneously reframing the problem into something more relevant to your program.
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.
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
.
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.