Ben Finney wrote: > "John Machin" <[EMAIL PROTECTED]> writes: > > > Ben Finney wrote: > > > Now that I've got it written as a Python module, I'd like to write > > > unit tests for that module, which of course will need to import > > > the program module to test it. The unit test can explicitly add > > > the directory where the program module lives to 'sys.path' for the > > > purpose of importing that module. > > > > If it can do that, it can copy the MUT to some temp directory, > > adding .py to the end of the name of the new file, and put the temp > > directory in sys.path .... can't it? > > Sounds like a nasty hack (not that fiddling sys.path isn't a hack, but > at least that one's addressed in Python 2.5 with relative and absolute > imports). > > The problem with importing the program module from a file in a > different directory is that the program won't be able to find its own > relative modules. That leads to either *more* sys.path hackery, or > importing from a temporary file in the *same* directory.
Please explain both the "own" and "relative" in "its own relative modules". Do these modules not have names that end in ".py"? > > Besides which, that's still two file names for the same module > code. The whole point of testing is to know that I'm testing the same > module; with a two-file shim, that's one step further away from that > ideal. The two-file caper exists only for the duration of the test. You'll have to trust yourselt to write and test a file copying gadget. :-) > > What you describe is possible, but leads to very smelly hacks. I'd > like to see what other options there are. > Probably smellier ones ...:<) Cheers, John -- http://mail.python.org/mailman/listinfo/python-list
