[TIP] Nosejobs!

Jesse Noller jnoller at gmail.com
Thu Apr 9 12:39:57 PDT 2009

On Thu, Apr 9, 2009 at 3:32 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Jesse, Doug, all,
> On Thu, Apr 09, 2009 at 14:54 -0400, Jesse Noller wrote:
>> > On Thu, Apr 9, 2009 at 2:27 PM, Doug Philips <dgou at mac.com> wrote:
>> [...]
>> >> Given the cross-polination between nose and py.test I would be suprised if this ability weren't already on the radar of the nose developers. Ideally it could be abstracted out for other testing frameworks to use too.
>> [...]
>> > And if py.execnet/py.test/any other open source work can save me time:
>> > I plan on absconding with it/using it. I'm not a fan of wheel
>> > recreation. Yes, I have looked at alternatives - my goal is to make
>> > this as automatic as possible, support multiple languages for tests,
>> > and *not* require that a test be written *for* the framework. A test
>> > should be as simple as a shell script, or as complex as you want, it
>> > should not have to know about the framework running it.
>> >
>> > -jesse
> Just to let you know: i share most of this world view and principles.
> I have an additional focus on zero-installation techniques,
> i.e. having code interact in a network such that I do not
> need to manually maintain server/client code.

I'm not that hung up about a simple server that delegates to
nose/another entity on each client. Any client should be as simple as
possible (with as few dependencies as possible).

I have the additional problem of pushing product installs to the
client (not just python modules - I mean, full blown installers).
Which means while I *might* be able to use SSH, I might need something
more for the server on the client to handle.

> Related to another post of yours: It's true that
> day long-running tests would be problematic for the current
> py.test/execnet code.  More async communication is needed in
> this case.  Maybe by reporting to an http-service where
> correlation is done by some unique test run id.  One can
> then do reporting and programmatically access the results.

Yup. That's the idea behind nosejobs: pass a UUID back to the caller,
the caller can circle back or be notified when the result is ready. I
don't want to have to have a constant connection to the test clients,
or the build slaves. They should be able to go off and do their thing
without maintaining one long connection.


More information about the testing-in-python mailing list