Re: [Boost-users] Boost filesystem feature request

From: Tristan Wibberley (tristan_at_[hidden])
Date: 2008-06-27 15:37:18

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.