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

[Remy Blank]

Peter Hansen wrote:
> Nevertheless, if you are really doing things in a test-driven fashion, 
> it should not be necessary to use __builtins__, if the open() calls and 
> such are in your own code.  In that case just create a reference to your 
> mock file system methods in the module under test, using the names 
> "open" and "stat" and so forth, and they will shadow the __builtin__ 
> names.  (Locals are found first, then globals, then builtins.)

That's a good approach when testing a single module. However, when 
testing multiple collaborating modules, doesn't it become difficult to 
ensure that all modules see the same stub functions? Or in the following 
case:

def FileSize(Path):
	import os
	return os.stat(Path).st_size

By sticking the functions into __builtins__ and os, all modules will see 
the same functions.

OTOH, I can imagine situations where one would want to have one module 
seeing the stubs, but others to see the normal functions.

> The idea of a standardized or at least widely used "full-featured" 
> virtual file system is an excellent one!  Writing tests that rely on the 
> real filesystem can be awkward and is probably one of the many small 
> things stopping/slowing some people from adopting TDD more.

Yes, it almost discouraged me, too. Well, I think I'll give it a try and 
come back with some actual code for feedback. Watch out for "mockfs"!

-- Remy

Remove underscore and anti-spam suffix in reply address for a timely 
response.