[TIP] Defining a convention for running tests, #2

[Robert Collins]

On Sat, 2010-02-27 at 22:12 +0000, Michael Foord wrote:

> > It is no less useful, but its not more useful either. If we define API
> > conformance instead, then python -m<runner>  somepackage.tests is no
> > less useful than *either* and can be more useful: runner glue can choose
> > result objects, provide command line handling that the user finds
> > atractive, provide parallel execution glue etc, while still being
> > standardised.
> >    
> 
> Except how does a project *specify* what the <runner> argument is 
> supposed to be?
> 
> This is the value a standard entry point provides.

They don't *need* to. Thats the point. You can use testtools.run,
unittest.run, nose, trial, zope runtests, subunit.run, unittestgui,
tribunal. If py.test adds a 'I can run a TestSuite' mode, then you can
use that too [and that could introspect for e.g. a py.test.TestSuite and
handle such things differently, to both interoperate and do 'native'
things.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20100228/24eb8578/attachment.pgp>