At 10:18 AM 12/14/2005 -0800, Todd Greenwood-Geer wrote: >test_[module_name].py
This is a common convention used by large Python projects. Other conventions include test/foo.py and tests/bar.py. >Then there's the issue of differentiating unit tests from functional >tests, scenario tests... I haven't seen any two projects use the same approach for these, I'm afraid. >Or am I overly complicating things again? If there's only one or two modules involved, definitely; small modules often include all their tests in the same file with the code! Python is very good for incremental, iterative development; try starting with the simplest thing that could possibly work, and only add complexity when you discover an actual problem with your current layout. Modern revision control tools like Subversion allow you to reorganize your source without losing history, so there's no need for you to worry in advance about what your layout will be when your project gets big. Start small and figure it out as you grow, and then you will have empirical data about how many tests you have, how big they are, etc., that will help you define an organization that works for your project. Currently, I would say that there is no community consensus as to a One Obvious Way to lay out tests for Python applications or libraries. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
