homepage

On Sun, Aug 1, 2010 at 11:05 PM, Eli Bendersky <report@bugs.python.org> wrote:
..
> The fake module was the least intrusive way I could think of to simulate stuff for trace.py -
> it's a scalable approach if I'll need more than one module in the future for some stress-
> testing. I haven't run into serious problems with this approach yet - the module is built
> dynamically, its attributes assigned as I need them, and that's all. Indistinguishable from a
> real module. This is what we love about Python's reflective properties :-)
I am not convinced. If you need more than one module - create a
package and put as many modules as you want in there. Your approach
has a namespace problem. Suddenly every other test writer need to be
careful not to use "fakemodule" name for his tests because
sys.modules["fakemodule"] may get clobbered. Note that your tests
don't clean up sys.modules after themselves, so if another test would
create fakemodule.py in a temporary directory, add that directory to
sys.path and import fakemodule (a reasonable test strategy), it would
get your left-over module.
You can deal with all such issues, of course, but the result is that
you will be testing a highly artificial setup. Even if this setup
faithfully reproduces a real use case, it is not obvious that it does.
 Best unit tests are those that are obvious. When a developer sees a
test failure, the last thing he wants to suspect is a faulty test.