[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.

-jesse



More information about the testing-in-python mailing list