<br><br><div class="gmail_quote">On Tue, Mar 2, 2010 at 15:14, Michael Foord <span dir="ltr"><<a href="mailto:fuzzyman@voidspace.org.uk">fuzzyman@voidspace.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On 02/03/2010 19:21, holger krekel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Feb 26, 2010 at 21:53 +0000, Michael Foord wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 25/02/2010 05:01, C. Titus Brown wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
here at PyCon there have been a lot of packaging discussions, so I thought<br>
I'd spend a bit of time outlining some suggestions for where to put<br>
tests and how to run them. It's been a bit of a thorn in the side of<br>
(among other things) continuous integration systems that there's no<br>
standard way to run Python tests... so let's fix that!<br>
<br>
I've produced a simple draft proposal& example where you put your unit tests<br>
under a package dir, somepackage/tests/.<br>
<br>
You can run these tests with<br>
<br>
% python -m somepackage.tests.run<br>
<br>
and you can also do (if setuptools/distribute is installed)<br>
<br>
% python setup.py test<br>
<br>
<br>
</blockquote>
If you're happy to depend on distutils2 and unittest2 then very soon<br>
there will be a standard "setup.py test" command that will continue to<br>
work with future versions of Python. It will probably default to<br>
unittest test discovery but allow you to provide a specific 'tests'<br>
argument (either a module or suite) and a 'testrunner' (test_runner ?)<br>
argument to specify a non-unittest runner if needed (testrunner defaults<br>
to unittest.TextTestRunner, well actually unittest2.TextTestRunner).<br>
<br>
</blockquote>
(i am on low bandwidth and vacation, just a quick note)<br>
I'd appreciate it if we had a more general mechanism<br>
than a unittest TestCase and a test runner. Maybe just a callable<br>
with some directory argument that is to discover and run the tests?<br>
After all there are non-python tests and non-TestCase tests these<br>
days and introducing a standard should be general enough for that.<br>
<br>
</blockquote>
<br></div></div>
There are three protocols suggested (and it would be nice to get that down to two... :-), none of which require tests to be TestCase based - although one of the protocols requires a test suite like object runnable with a TextTestRunner. As I explain below this is a very minimal requirement. The three protocols we have discussed are:<br>
<br>
Packages provide a test sub-package with a run module that is able to collect and run the tests when executed with:<br>
<br>
python -m package.test.run<br></blockquote><div><br></div><div>Can I suggest this change to package.test.__main__? The reason for this is that starting in Python 2.7 and already in Python 3.1 is support for executing packages through runpy. The __main__ module in a package is what gets called and executed as '__main__'. It works out really nicely as the execution line would become::</div>
<div><br></div><div> python -m package.test</div><div><br></div><div>Which does not require remembering the specific name of the module to execute. Plus it is backwards-compatible with older versions of Python that support -m::</div>
<div><br></div><div> python -m package.test.__main__</div><div><br></div><div>I am already using this in the stdlib for importlib and I am quite happy; it's become my preferred way to execute tests by hand when doing development. Plus it provides a nice place to provide command-line parsing when I have to tweak something (in my case using __import__ instead of importlib for quick compatibility tests through a --builtin argument).</div>
<div><br></div><div>-Brett</div></div>