Running file-based unit tests in an environment which does not allow access to the file system

This arises from a programming exercise which a company recently sent me as part of a job recruitment process.

The test was to write a Java 5 program which reads data files from a specified directory, or any sub-directories below it, reads the contents of the files, and prints summary information to the screen. The files simply contain integers (one integer per line) and the program simply counts the number of files it reads, the total number of integers it finds and the sum of these integer values. The program is to print error messages if any files are unreadable, or contain any entries which cannot be parsed into integers. The submission must also include unit tests for all the included classes.

So far so easy. But there was a paragraph in the specification which basically stumped me:

"We expect unit tests for your code, however there is one complication: the unit tests will run in an environment which does not allow running Java code access to the file system (for example, a cloud computing grid). As such, the design of your code will need to take this limitation into account, and be designed to still allow as much unit testing as possible."

The code I actually submitted used the java.io.File class to examine the directory structure and store the names of data files, which I then used to instantiate BufferedReaders from which I could read the data values. For the unit tests, I simply created a local test directory containing known data files, and tested that the methods gave the correct values for these test files.

The company failed my submission, saying that I had missed the point of the paragraph about the Java code not being able to access the file system. In fact I had noticed the paragraph, I simply do not understand what to do about it! I do not know any alternative approach to the one I used. The company were clearly right to reject me, given that I do not know the correct solution method to their exercise. They have so far declined to give me an explanation of what the correct approach is.

So I post it here in the hope that someone can help me understand this. Can you refer me to a Java class which I could look at, or a web site or text book which would have describe an acceptable solution method, preferably with examples?

Obviously, when in doubt with client requirements, the correct answer is always to ask. Of course, this is a test, so that option is not available.

Personally, I think it would be weird to do unit tests of the code that reads from files, when you are not allow to read from files.... but maybe it is for the unit testing of code that is using your code. In that case, if I am not allow to access the file system, I'll create a local environment, but not the way you did it.

Since I can't read from files, I'll create local array buffers with the data, and then create BufferedReaders from the array data instead of the files. For this to work, it will also need to have a flag to change the behavior needed by the unit tests.

Henry

Thanks for posting, Henry, but I am not sure I follow your suggestion.

What I think you mean is:

1) Write a @BeforeClass section in the unit test suite which creates the data files from scratch, using BufferedWriter. Put these files in a known local directory structure
2) Write the unit tests as before
3) Write an @AfterClass section which deletes the test data files and their directory structure.

I do not understand your suggestion about putting a flag in the unit test suite. These three lines seem to cover it all.

I can see merit in this suggestion. If the Java code creates and deletes all its own data files, there is no need to save any files locally. But physical files do exist while the test suite is running, and they must be stored somewhere. And given that the project needs a folder structure anyway (src/main, test/main etc) why not incorporate some folders at the same level which save the test data files? It all comes down to what they mean by "the running Java code does not have access to the file system" which I find rather unclear.

Have you, or any other readers, actually written unit tests which have actually been deployed in an cloud environment? Did this force you to change the way you wrote your code and unit tests, and if so how?

It seems be a TDD rule that unit test should not allow access to the file system.
Let me know if you have the answer!

I did not know the rule that "Unit Tests must not access the file system" but create their own local files instead - but this does not mean it is not true. Can you refer me to any web articles, blogs or text books where this is discussed?

A set of unit test rules by Michael Feathers:
http://www.artima.com/weblogs/viewpost.jsp?thread=126923

Gary,

The important thing about that mystery paragraph, I think, is that knowing about this limitation should influence the design of your code. For example, you've presumably got some code which sums up the integers read from a file. If that code only works when given a java.io.File, then it obviously can't be tested in the absence of a file system. But if you've designed things like this, for example, then it could be:

because you could create a StringReader containing the data, then wrap it in a BufferedReader and pass it to the method. Some of the code can't be tested -- some of the code has to look at the filesystem. But some parts don't need to, and those parts can be tested. The trick is to design things so that the largest possible fraction of the code is testable.