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.