[TIP] nose2 backwards compatibility questions

[Kumar McMillan]

On Mon, Aug 9, 2010 at 11:49 AM, jason pellerin <jpellerin at gmail.com> wrote:
> Some questions for nose2-philes.
>

As a general rule of thumb, any backwards incompatible change in Nose2
would benefit from having a well documented step by step set of
instructions for migration.  If the instructions are easy to follow
and the feature is hard to implement then the instructions should
probably suffice.


> 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 and looking in test* dirs even
> when they aren't packages. Do we want nose2 to support that too? Even
> if it requires overriding private methods in TestProgram (which it
> will, as things stand)?

Ah, test layout.  There are scenarios that, I fear, would not be
*easy* to migrate if, say, support were dropped for all the crazy
layouts that Nose supports.  Along what Michael said, maybe it's easy
to implement all the same test discovery, preferably as a plugin
though because IMHO there are some layouts that Nose support which
makes things confusing (e.g. module unloading) and should be
deprecated.  That is, not ported to unittest2!

Can Nose's importer/loader test be repurposed to understand what such
a plugin needs to do?
http://bitbucket.org/jpellerin/nose/src/tip/functional_tests/test_importer.py
http://bitbucket.org/jpellerin/nose/src/tip/functional_tests/test_loader.py

>
> 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?
>

I doubt this is worthwhile.  It sounds like there will be a fairly
easy and straightforward way to register plugins globally (via a
config file) in unittest2 so as long as these instructions exist in a
migration doc then porting plugins over should be fine.  Well, the
discovery of said plugins at least.

On a side note, I do prefer something more "zero config" similar to
how entry points worked.  Nice write-up on it from Tarek:
http://tarekziade.wordpress.com/2010/07/25/plugins-system-thoughts-for-an-entry-points-replacement/

> 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?

Again, I think it might make the most sense if alternate test
discovery / loading processes were done in plugins.

>
> 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?

There are a lot of people using Nose for very big test suites [1].
I'd guess a good amount of those suites will want to port to nose2 at
some point.  If the migration steps are minor then that's probably
sufficient otherwise the more features that are ported over the
better.  I think if people want a clean break then they can probably
just switch to unittest2, right?


[1] I guess maybe this is some indication of adoption?
http://www.activestate.com/blog/2010/07/survey-says-selenium-nose-most-popular-test-framework
(no idea how many people answered that survey).  Or that the latest
Nose has 5,000+ downloads.

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