[TIP] Nosejobs!

Michael Foord fuzzyman at voidspace.org.uk
Fri Apr 10 10:52:49 PDT 2009

C. Titus Brown wrote:
> On Fri, Apr 10, 2009 at 01:41:07PM -0400, Doug Philips 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. :)
> I'm sure you want to know: What Would Titus Do?
> Well, I have some insight there... he would probably implement a simple
> wrapper that used subprocess to run things & kept an eye on the process,
> killing it if it got wedged etc.  Reporting would be accomplished by
> that wrapper.

That's exactly what we do in our distributed test runner that automates 
our UI (and is prone to occasional freezes). We kill wedged processes 
and report this to the database that is collecting test run information.

> Then he would chase down the corner cases with an axe or a baseball bat,
> depending on how he felt that day.
> Seriously, there are very few unsolved problems in the kind of thing
> that Jesse is talking about, merely the complexity of fitting them all
> together and choosing the right tradeoffs.  It's not a technology
> problem -- it's a design problem.
> --titus
> p.s. Actually, what I would do is release the first iteration that
> solved about 60-80% of people's problems, promote it wildly on this list
> and through my blog, and then stop working on it.  In about a year,
> people would then start making really straightforward and obvious
> suggestions to improve the thing, and I'd be forced to either integrate
> their patches or give up on the package.  Based on an n=2, that is what
> would happen...


More information about the testing-in-python mailing list