On 21 Nov., 04:16, Jens <[EMAIL PROTECTED]> wrote: > On 21 Nov., 01:46, [EMAIL PROTECTED] wrote: > > > > > On Nov 20, 4:09 pm, Jens <[EMAIL PROTECTED]> wrote: > > > > Dear Reader, > > > > I'm writing some modules in Python, and I'm also using unittests. I'm > > > wondering about some things: > > > I'd love to hear how others manage this sort of thing as well. I'll > > describe what I've found works best for me, and if others do the same, > > maybe we can all learn from each other. > > > > 1) Should I put my unittests in a subdirectory? Does the subdirectory > > > have to be a package? > > > I put them in a subdirectory and make it a package. The biggest > > advantage I see of using a subdirectory is that I can have lots of > > test scripts and it's easy to keep them organized separately from > > production code. The biggest disadvantage is that if I run the test > > scripts from inside that subdirectory, they need to import modules > > from their parent directory, and I'm using Python 2.4 which doesn't > > have relative imports. So I put a .pth file in my site-packages > > directory that adds the top-level package of my project to the > > pythonpath. Then the test modules can import production code using > > the fully qualified package.subpackage.module name for each production > > module being tested. > > > > 2) Does the main folder /myproject have to be a package? Should I put > > > my modules directly under /myproject, or should I create a subfolder, > > > for example /myproject/modules > > > I make all non-trivial projects into packages. It allows me to do the > > trick with a .pth file I described above. It makes it easier to reuse > > all or part of my project as a component of a second project. And it > > makes creating documentation with epydoc easier. > > > I typically lay out a project directory something like this: > > > projectname/ > > setup.py > > dev_install.py # automatically creates .pth file in site-packages > > alltests.py # runs all unit tests > > main_package_name/ > > __init__.py > > module1.py > > module2.py > > doc/ > > img/ > > subpackage1/ > > __init__.py > > module3.py > > module4.py > > tests/ > > __init__.py > > test1.py > > test2.py > > subpackage2/ > > etc.... > > > With this setup, tests are organized by subpackage, and each test > > script can be run by itself, or all together from alltests.py. If a > > module in subpackage2 needs to import a module from subpackage1 > > (generally a sign of poor design, but it happens), it would need to > > use the fully qualified "import > > main_package_name.subpackage1.module1". Each time I check a new copy > > of the project out from version control to a new location, I have to > > make that the "active" version by running dev_install.py, which puts > > a .pth file in site-packages that adds the newly checked out path to > > the pythonpath. As long as I remember that step, this approach works > > well. > > > > Does anyone have any "best practices" as to how to manage your code? > > > > Thanks! > > > If anyone does, I'd love to hear about them. > > > -Casey Raymondson > > Thank you very much for your ideas! I'm trying to make it work, and > have created a small example: > > dummy/ > dummy_package/ > __init__.py > moduleA.py > tests/ > __init__.py > test.py > > I'm using Python 2.5.1. When I'm trying to call a function in > 'moduleA' from 'test' it won't work unless I make the 'dummy' folder a > package as well. That's pretty weird. Does 'dummy_package' have to be > in my pythonpath or something? How do I reference moduleA from test? > > I would like to avoid making 'dummy' into a package as well.
Problem solved. I added 'dummy' to the PYTHONPATH. (Do I really have to do that for every project I create?) Anyway, it works the way I'd like it to now. -- http://mail.python.org/mailman/listinfo/python-list
