Has anyone released a Python "mock filesystem" for automated testing?

[Bengt Richter]

On Thu, 04 Nov 2004 21:31:04 -0500, Peter Hansen <peter at engcorp.com> wrote:

>The term "mock filesystem" refers to code allowing unit
>or acceptance tests to create, read and write, and manipulate
>in other ways "virtual" files, without any actual disk
>access.  Everything is held in memory and therefore fast,
>without risk of damaging real files, and with none of the
>messiness of leftover files after testing.
>
>Googling the archives and the web suggests that only I and
>Remy Blank have done much along these lines.  I don't see
>any sign that anyone has actually released such a beast
>yet, however.
>
>My own past work in this area was always proprietary, and
>as "you can't take it with you" I've been starting over
>on a new project and have the basics working.  If nobody
>can point me to a more complete implementation, I'll be
>happy to continue to work on mine and release it in the
>near future.
>
>For now, in case anyone is interested, I have support
>for basic open, read/write, __iter__, close, "r" and "w"
>modes, a couple of the most basic exceptions, and a
>tiny handful of lesser things.  All well supported by
>their own unit tests, of course, to ensure quality.
>Stripped class/def lines shown below, as that may be
>an easier way for you to picture what this is about:
>
>class MockFile(object):
>     def __init__(self, fs, path, data='', mode=''):
>     def _getContents(self):
>     def read(self):
>     def write(self, data):
>     def close(self):
>     def __iter__(self):
>
>
>class FileSystem(object):
>     '''Acts like a real file system to support testing.'''
>     def __init__(self, mocktime=False):
>     def _createFile(self, path, data):
>     def _getFile(self, path):
>     def open(self, path, mode='r'):
>
>Thanks for any pointers to more advanced stuff.
>
In a recent post, I suggested a way to virtualize selected files or glob-pattern
sets of files specified by string.

The idea was/is to make open and/or file check whether the path it's being passed
has been registered in a hook registry of substitute classes or factory functions
to be called instead of the normal file builtin functionality, so that the returned
object is an instance of _your_ registered custom class.

"Registering" might be as simple API-wise as sys.filehook['filename.ext'] = MockFile
(to use your example ;-)

*args, **kw would be passed to Mockfile and the resulting instance would be passed
back to the caller of file, so e.g. file('filename.ext', 'rb').read() would
have the effect of Mockfile('filename.ext', rb').read()

Of course there are a bunch of other file things that might have to be supplied if
you wanted to virtualize using low level os.open & friends.

Re a whole file system virtualization, I tried to float that one time long ago, but got
no enthusiasm, even though I only wanted to introduce a virtual branch of the root.

If you do do something with a VFS, IMO it should be mountable and require mounting. Maybe
unix-style mapping of the file tree like msys does for windows would allow mounting
in a platform-independent way, referring to c:\some\path\ as /c/some/path/ and so forth.
Not sure about virtualizing fstab... I guess you could do os.filehook['fstab'] = Something
to feed something special to the mount.

With a mount command you could also specify text file cooking or not, etc.

Just stirring the pot, but I think it would open up some different testing possibilities ;-)
If the hook really hooks well, I would think you could write

    sys.filehook['foo'] = __import__('StringIO').StringIO("print 'hi from dummy foo.py'\n")
    import foo

and expect a greeting (the first time)(untested ;-)

I guess it depends on where i/o funnels back to common layer interfaces.

Regards,
Bengt Richter