0

I am writing an application in c++ and Qt5. It would be very convenient for me to create a virtual file system so I can unit test code working on files.

I have found that in Qt4 there was a QAbstractFileEngine class which would perfectly match my needs, but it was removed (from public interface) in Qt5.

The only thing which comes to my mind is to create needed file structure in a temporary directory and work on it, but that's not a perfect solution (both in terms of unit tests and my case).

Are there any other options? I need a solution working on both linux and windows.

1 Answer 1

5

The only thing which comes to my mind is to create needed file structure in a temporary directory and work on it, but that's not a perfect solution

Did you try it? This solution works well for many cases, is dead simple and does not give you any headache for solving your "Linux and Windows" requirement. As a bonus, all created files by the code under test will usually be there after the test. So in case a test fails, they may be utilized to find the root cause.

The only thing I know where a temporary directory differs really from a "virtual file system" (or a file system in a ram disk) is performance. But as always with performance, I would heavily recommend against optimizing "just in case". Only invest time in optimization if a simple solution really does not meet your performance requirements, which is impossible to tell if one does not try it out.

My practical experience with this is that our team used the real file system for lots of automated tests, and in almost any case the performance was good enough (and where it was not, we found other ways of optimization). Those tests might not be "unit test" in the narrow sense, but using a virtual file system won't really change this. A test which uses a filesystem is most probably not a unit test "by the book" any more, if the file system is real or virtual or on a ram disk.

Another approach, as mentioned in the comments by @RobertHavey, is to encapsulate all file system access in a separate class and mock this out. That may result in "unit tests by the book", but it can require a lot of work to make such a mock providing the test environment which behaves "real enough" to become useful.

16
  • 5
    @MichałWalenciak: I am pragmatician, and I recommend not to stick superstitiously what some book has told you what a unit should be or not should be. Use what works, and only when it does not work well, then try to improve, not the other way round.
    – Doc Brown
    May 10, 2020 at 18:30
  • 1
    @MichałWalenciak: It sounds like what you need is a mock object. It doesn't have to simulate the entire OS; all it has to do is respond with the appropriate signals to get your test accomplished. For example, simulating read/write errors or operations without proper privileges. May 10, 2020 at 19:35
  • 5
    @MichałWalenciak: why do you not clearly state in your question what expectations or requirements for your "fake file system" you have which a real file system does not fulfill? Saying "that's not a perfect solution" is quite unspecific. And do you really have such requirements for your real-world system, or do you just invent them now because you don't like my answer?
    – Doc Brown
    May 10, 2020 at 20:44
  • 3
    @MichałWalenciak: Frankly, arguments like "I am purist when it comes to UTs" and "using real filesystem is against definition of unit tests" sound more like a creed to me, a religious believe, not factual reasons. If you have clear requirements for your tests, please edit your question and put them in there; in this comment section most other readers will overlook them.
    – Doc Brown
    May 10, 2020 at 21:42
  • 2
    +1. ROI on mocking the filesystem is usually pretty low, in my experience. There could be exceptions, but I expect you'd just fully mock the filesystem in those cases. E.g., if the nature of your application is to help with file system cleanup or otherwise potentially destructive, the risk of not mocking is high. You'd want to fully mock FS for testing if that's the category you're in. But, if that's your situation, maybe write an adapter layer, tested directly against the FS, and then a parallel mock of the adapter. (Which I only assume will be easier to mock in full.)
    – svidgen
    May 11, 2020 at 14:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.