"Virtual" file system mock object - replacing stuff in __builtins__

[John Roth]

"Remy Blank" <remy.blank_asps at pobox.com> wrote in message
news:404844e3$1 at epflnews.epfl.ch...
> Hi everybody,
>
> I find myself writing lots of small utilities these days that need to
> iterate over a file system tree and perform operations on every file,
> e.g. setting ID3 tags or generating playlists or <plug> archiving files
> (sync2cd: an incremental archiving tool to CD/DVD at
> http://www.calins.ch/software/sync2cd.html) </plug>.
>
> As a big fan of Python, that's the language of choice for these tools.
> By the way, this is my first posting, and therefore also my first
> opportunity to thank all the people who help providing such a great
> language!
>
> As a fan of TDD (test-driven development), I use the unittest module to
> write the test cases for these tools. However, to make the test cases
> independent of the file system environment, I simulate a file system
> tree with a mock object using the following technique (sorry for the
> long posting):

[example snipped]


> Now my questions:
>   - Am I doing something fundamentally forbidden (replacing stuff in
> existing modules like __builtins__ or os)?

Yes. It's never a good idea to replace stuff on the system
level, and some day it might become impossible.

>   - Is there a better way of achieving the same result?

Well, I don't know about "better" but what I've discovered
is that file system scans are ideal usages of the Visitor pattern.
I've got a single module that contains the guts of the file
system scanner and a number of useful utility methods (such
as loading a file into memory, writing it out and setting the
stats).

My scanners are basically just visitor objects that have
"doDir" and "doFile" methods. In this system, new code
doesn't have to go near the file system at all: it's all in the
scanner and the utility functions.

Writing a new visitor using TDD is trivial since what I
have to write doesn't have to deal with any file system
calls. Everything I have to mock is my own code.

>   - If the technique is generally useful, would there be interest in
> having a full-featured "virtual" file system mock object? I couldn't
> find anything similar on Google.

I don't currently have a need for it.

John Roth
>
> Thanks.
> -- Remy