[TIP] Nosejobs!

Michael Foord fuzzyman at voidspace.org.uk
Fri Apr 10 11:21:08 PDT 2009

Jesse Noller wrote:
> On Fri, Apr 10, 2009 at 1:41 PM, Doug Philips <dgou at mac.com> wrote:
>> On or about Thursday, April 09, 2009, at 03:01PM, Jesse Noller indited:
>>> Let me also point out that I want something to start running tests
>>> which could run for a week+ - I have internal tests which could take
>>> 14 days to run. I don't feel like maintaining a client/server
>>> connection for that long.
>> If the test dies after 30 minutes and you don't find out about it for 13+ more days?
>> There has to be a middle ground between a constant connection and a moon shot. Even moon
>> shots steer along the way. :)
> Simple, solved problem. The master(s) track outstanding jobs and check
> on a customizable interval, if the slave fails to report: It's dead,
> if the test-runner fails to report to the client-server after the
> client-server gets a poll from the slave; it's either busy, or dead.

Advantage of controlling the tests on the slaves with a master process 
(but we're into implementation details here) is that it is easy for it 
to continue its scheduled tests after a wedge. We also use this so that 
individual test processes can be restarted after their memory use gets 
too high.

> Ideally, part of a "test's spec" is how long, on average, it takes
> (you can track this via results, too) - if the test strongly deviates
> from this value, you can choose to pull the plug, or otherwise take
> over manually. There are a lot of options here.
> jesse
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python


More information about the testing-in-python mailing list