"Virtual" file system mock object - replacing stuff in __builtins__
Remy Blank
remy.blank_asps at pobox.com
Tue Mar 9 04:28:57 EST 2004
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.
More information about the Python-list
mailing list