[py-dev] core design of py.test broken?

[holger krekel]

On Wed, Jan 05, 2005 at 01:04 +0100, Laura Creighton wrote:
> <snip>
> 
> >Of course, there are some other side issues to consider, like
> >that py.test manages to run tests in the same order they
> >appear in a file. But this probably affects implementation,
> >not the idea so much. 
> 
> Sometimes, of course, what you really want is a way to make sure that
> the tests are _not_ run in the same order that they appear in a file, because
> that ordering hides a bug, which you don't know about, because you always
> do them in that order.  Being able to specify that would be neat.

sure, it shouldn't be a problem to optionally don't care for ordering, 
maybe with specifiying "--random" or so.   
 
> >Another somewhat unexplored area: having very interactive 
> >testing frontends, think pygame, wxPython or web-driven. For
> >this the underlying design choices need to be accessible 
> >and manipulatible in a user-event-driven and very custom way. 
> 
> I think that the people with a huge amount of tests want, among other things,
> a way run a nightly build that goes through all the tests and see if something
> inadvertantly broke.  I worry about how well that will play with being
> user-event driven.

Running in linear batch mode is easier on the implementation than 
to allow full interaction with crazy users in a highly customized environment.  
After all you could see a batch job as something with very low 
user interaction :-)  Regarding batch mode it is probably more interesting 
to look at the "Reporter" side, which is a somewhat different can of worms. 

cheers, 

    holger