[Python-ideas] Adding a test discovery into Python

Jesse Noller jnoller at gmail.com
Sun Feb 1 18:21:42 CET 2009

On Sun, Feb 1, 2009 at 12:10 PM, Guilherme Polo <ggpolo at 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)
> 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.
> Thanks for reading,
> --
> -- Guilherme H. Polo Goncalves

I think reinventing something which has been implemented ad-nauseam in
the community (py.test, nose, etc) would be silly. I'm biased towards
nose (really biased) - but I think using the discovery core of one of
these might be good.


More information about the Python-ideas mailing list