[TIP] Nosejobs!

[Michael Foord]

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.

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


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog