[TIP] nose2 backwards compatibility questions

[Michael Foord]

On 09/08/2010 17:49, jason pellerin wrote:
> Some questions for nose2-philes.
>
> 1) How much do you care about nose-style test discovery? nose does a
> bunch of extra work to support real-world package layouts, such as
> prepending ./lib and ./src to sys.path
This you should still be able to do without issue, right?

> and looking in test* dirs even
> when they aren't packages.
Do you do this recursively - or just at the top level?

> Do we want nose2 to support that too? Even
> if it requires overriding private methods in TestProgram (which it
> will, as things stand)?
>
>    
When I implemented test discovery I knew that it was much less capable 
than nose, but as I didn't know what the full rules about how nose did 
discovery and how it resolved any difficulties / ambiguities (etc) I was 
very conservative in my initial implementation.

I would be happy to discuss ways of making discovery more flexible in 
unittest(2).

If you find test* directories that aren't packages, how do you turn them 
into modules? Do you add that directory to the path then just import 
them? (Do you then remove the directory from the path once you have 
imported everything?)

Do you recurse into *all* directories looking for test* directories, or 
just into packages (with the addition of src/ and lib/ as potential 
starting points)?


> 2) Is attempting to provide compatibilty with nose 0.9/0.10 plugins
> (found via the setuptools entry points) worthwhile, even if it will be
> limited? It definitely will be, maybe as limited as allowing
> configuration only through the command line *or* only through config
> files, but not both. Is it worth spending the nontrivial amount of
> time that will be required to see if this will work?
>
> 3) Is it worthwhile trying to patch in nose's importer? nose's
> importer allows tests to be organized in directories instead of
> packages, even when the module names overlap. Is that a real-world use
> case that we need to continue supporting?
>    

Could we provide a plugin point that makes it easier to customize 
discovery without you having to override private methods?

> The meta question in all of this is how much work we want to do to
> make test suites that work with nose now, work with nose2 without
> major changes. Is that a main priority, or is nose2 a clean break with
> no implied promise of compatibility?
>    

*Personally* (and my opinion doesn't count as I'm not a nose user) is 
that it is worthwhile for nose to support the same test features / 
project layouts where this is possible (along the way losing any 
features that aren't widely used or are more trouble than they are 
worth). Supporting existing *plugins* is going to be a lot of work though.

For "entry point" type configuration unittest(2) will use PEP 376 which 
will have a backported implementation for Python 2.4-2.7 (plus 3.0-3.1) 
in disutils2. Alongside I will implement a plugins subcommand or 
separate script for easy plugin discovery and management without 
*needing* to mess around with configuration files. (Basically the 
plugins command will manage the config files for you which will still be 
fully supported.)

All the best,

Michael

> Your thoughts?
>
> Thanks,
>
> JP
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>    


-- 
http://www.ironpythoninaction.com/