nose2: the jazz odyssey begins
jason pellerin
http://pypi.python.org/pypi/nose2/0.1
nose2 is a reimagining of nose, following the trail blazed by Michael
Food in the unittest2 plugins branch. Someday, nose2 will probably
become just a collection of unittest2 plugins. For now, it is a plugin
engine *and* a collection of plugins (but neither a floor wax nor a
dessert topping).
This is a very, very, very early release, and useful mainly (if not
only) to those who want to start contributing to nose2, or check out
the plugin api and start writing plugins that abuse it.
You can read the docs here:
http://nose-devs.github.com/nose2/index.html
(for now, we'll probably move them to readthedocs.org someday)
Development is happening here:
https://github.com/nose-devs/nose2
Come join us! Or there might not be a release 0.2. No pressure, though.
JP
LiuCougar
I don't see multiprocessing plugin being mentioned in the nose2 doc anywhere. is it one of the things which won't be available in nose2? (I could not find a list of plugins which can't be ported to nose2)
thanks,
Heng
Director of Software Development, teampatent.com
生于忧患，死于安乐
"People's characters are strengthened through struggle against difficulties; they are weakened by comfort."
- Old Chinese adage
JP
--
You received this message because you are subscribed to the Google Groups "nose-users" group.
To post to this group, send email to nose-...@googlegroups.com.
To unsubscribe from this group, send email to nose-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nose-users?hl=en.
jason pellerin
> Hi jason,
> I don't see multiprocessing plugin being mentioned in the nose2 doc
> anywhere. is it one of the things which won't be available in nose2? (I
> could not find a list of plugins which can't be ported to nose2)
Hi Heng,
Multiprocessing is not there in nose2 yet but there definitely will be
some kind of test distribution/parallelization plugin. Right now I'm
still thinking about different ways to approach the problem and not
ready to start coding yet. If anything it should be easier with
nose2's plugin system and non-lazy test collection, but "easier" isn't
"easy" ...
The things that won't work in nose2 are basically the ones in nose
that depend on test collection being lazy: weird project layouts where
modules shadow each other, and plugins like the isolation plugin that
assume a test module is imported and run before other test modules are
imported.
JP
jason pellerin
<mic...@voidspace.org.uk> wrote:
> On 20/01/2012 15:18, Michael Foord wrote:
>>
>> On 20/01/2012 14:07, jason pellerin wrote:
>>>
>>> 2012/1/19 LiuCougar<liuc...@gmail.com>:
>>>>
>>>> Hi jason,
>>>> I don't see multiprocessing plugin being mentioned in the nose2 doc
>>>> anywhere. is it one of the things which won't be available in nose2? (I
>>>> could not find a list of plugins which can't be ported to nose2)
>>>
>>> Hi Heng,
>>>
>>> Multiprocessing is not there in nose2 yet but there definitely will be
>>> some kind of test distribution/parallelization plugin. Right now I'm
>>> still thinking about different ways to approach the problem and not
>>> ready to start coding yet. If anything it should be easier with
>>> nose2's plugin system and non-lazy test collection, but "easier" isn't
>>> "easy" ...
>>
>>
>>
>> The test runner should be able to be run as a master or slave with a
>> protocol for communicating results from slave to master. The master does
>> test collection and launches slaves (either locally or remotely) with the
>> same configuration as the master (plugin state, command line args etc as
>> appropriate).
>>
>> Slaves then ask the master for tests and communicates the results back.
>> The master creates the test report. All objects attached to test reports (by
>> plugins on the slave) must be serializable.
>>
>
> This would all be done in as a plugin (naturally). I specifically included a
> hook point that allowed a plugin to completely take over the running of
> tests for this purpose.
>
> I had in mind using subprocesses rather than multiprocessing specifically.
> So I'm not entirely sure we're even talking about the same topic... Oh well.
> :-)
We are! Your approach above is basically what I've been thinking of as
"option A" (even down to using subprocess or execnet instead of
multiprocessing to launch the slaves). Option B, which I'm still
thinking about so it may be impossible or impractical, would be to use
concurrent.futures and a much dumber slave side that just runs test
cases/suites and records the hooks and events they want to fire, then
sends those back to the master as the future's return value. The
master then "plays the tape" to fire the real hooks with real events.
Might work, might be nice and simple... haven't thought it through
yet.
JP