[TIP] nose2 backwards compatibility questions

[Michael Foord]

On 10/08/2010 14:40, Michael Foord wrote:
> 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?

Ah no, it requires continuing discovery into these directories - with 
them as the top level directory - even though they don't contain an 
__init__.py. I will propose a fix to the TestLoader that allows this to 
work.

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

For this I still want to understand what is allowed (and how it works) 
in order to either allow it to be done through a plugin or making it 
possible in the standard test discovery machinery. Allowing handleFile 
to be called on files that wouldn't normally be loaded at all would be 
one way - a bit brutal though perhaps as you then have to create the 
module yourself (skipping plugins that do pattern matching) as the 
standard loader wouldn't know how to turn the path into an importable name.

All the best,

Michael

>> 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/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.