Boost filesystem feature request
Hi Boost devs, I'm looking for a way to write programs with unit tests that don't hit the real filesystem, so there is no cleanup necessary in the event of a segfault, and so that tests run fast and set up is simple. Is the any chance of a future version of boost filesystem implementing the ability to do operations to a memory-based data structure that simulates a real filesystem. It would be especially useful if such a mock filesystem could be configured with failures that should occur to test error handling paths. It would be pretty vital that a test program could still use the regular boost filesystem for its own implementation to access the disk and that several separate filesystems could be mocked at the same time to test client-server application components within a single process. Thanks for listening -- Tristan Wibberley Any opinion expressed is mine (or else I'm playing devils advocate for the sake of a good argument). My employer had nothing to do with this communication.
I'm looking for a way to write programs with unit tests that don't hit the real filesystem, so there is no cleanup necessary in the event of a segfault, and so that tests run fast and set up is simple.
Just an off-the-cuff response, but depending on your OS, you might be able to use a RAM-disk, or some memory-based filesystem. Solaris has tmpfs I think. I believe you can still do it in Windows 2000+ http://channel9.msdn.com/forums/TechOff/19142-Microsofts-XP-RAM-Disk-Driver/) But that might have a size limit of 32MB. Anyways, maybe a different approach you hadn't thought of. -Dan
On Fri, 2008-06-27 at 08:22 -0500, Dan Thill wrote:
I'm looking for a way to write programs with unit tests that don't hit the real filesystem, so there is no cleanup necessary in the event of a segfault, and so that tests run fast and set up is simple.
Just an off-the-cuff response, but depending on your OS, you might be able to use a RAM-disk, or some memory-based filesystem. Solaris has tmpfs I think. I believe you can still do it in Windows 2000+
It would make testing my current program possible, but it would be much less than ideal requiring much configuration of the local machine instead of being self contained. It would also require ugly set-up and tear-down scripts. I'm thinking of writing my own non-singleton interface with operations as methods on a filesystem object with the only singleton being the method of getting a reference to the local system's real filesystem object. If I wrap boost filesystem like that with a highly similar filesystem interface and fstream classes then I can implement alternative memory backed filesystems in the test process that I can derive from to cause all sorts of failures in arbitrary numbers of combinations. The problem with this not being in the boost filesystem library, though, is the high maintenance and research costs for accurately simulating the edge cases of various platforms that I will eventually want to support (simulating them is vital as it's the only way to make them happen reliably, on demand).
Anyways, maybe a different approach you hadn't thought of.
Yes, I'd thought of that, but operating systems are not designed to aid unit testing and I've long disregarded it, especially for units that use the operating system's filesystem interface. Filesystems, synchronisation, and time events are some of the biggest things that I consider leave a unit pretty much wholly untested if not mocked and edge cases simulated. -- Tristan Wibberley Any opinion expressed is mine (or else I'm playing devils advocate for the sake of a good argument). My employer had nothing to do with this communication.
participants (2)
-
Dan Thill -
Tristan Wibberley