On Sun, Feb 1, 2009 at 09:10, Guilherme Polo <ggpolo@gmail.com> wrote:
Hi,
I believe it would be good to include a test discovery into Python, right now I notice all the following packages:
bsdbb, ctypes, distutils, email, json, lib2to3 and lib-tk (tkinter in py3k)
... and importlib.
duplicate some form of test discovery that works for each one of them (there are also sqlite3 tests, but they are not using a real "test discovery"). In the future it is very likely that this "duplication count" increases, since from time to time new modules and packages get into Python. I can also feel the "idlelib" package starting getting tests, just making things worse.
External packages would benefit from it too. Right now you either duplicate the test discovery once more (because your project is small enough that you don't want to use something specific for that), or you use nose, trial, py.test or whatever looks better for you.
So.. is there any chance we can enter in agreement what features would be useful in a test discovery that could be included with Python ? I for myself do not have fancy wishes for this one, I would be happy with something that would collect unittests, inside packages and subpackages, with some fixed patterns and let me run them with test.test_support.run_unittests, or maybe something that would collect unittests and doctests and have something like run_tests in test.test_support. But then I believe this wouldn't be good enough to substitute any of the current tools, making the addition mostly useless.
Yep. I want to be able to state "find the tests in this package and search the entire package top-down looking for tests to run". The only trick is if you store the tests in something other than on the file system directly (e.g. zipfile). That would require a little bit more work like having modules listed in the __all__ value of the package and use that to know which modules to look in. -Brett -Brett