Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
On Sun, Aug 1, 2010 at 11:05 PM, Eli Bendersky <rep...@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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9315> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
