2012/11/7 Andreas Gudian <[email protected]>: > Hey guys, > > thanks for your input. Kristian, I'd like to start with your concerns about > the threading in the forked process. With the code as it is now, you are > totally right, that threading in this LazyTestsToRun class is not really > required. It's a left-over from a previous attempt where the forked servers > did not /ask/ to receive more work, but were that was pushed to them > implicitly, with a special RunListener reacting on finished tests. The only > advantage now left is that with the decoupled threads we can react on a not > responding (hanging) main process, as I can easily observe a timeout with > different threads. Being stuck in an InputStream#read() method might get us > into trouble. But perhaps it's just paranoia and everything will unravel > once the parent process gets killed.
Having given this some more thought and corrolated with Dawid's mail, I think the main concern with free-running forks is in the logging/reporting bits. I'm still a firm beliver that *more* threads never make things simpler and I think you should clean up the patch without the threading; we can always add that later. I still think that latency has lost much of its relevance with lots of threads ;) > > I guess another thing needs to be sorted out before deciding on whether to > drop the extra threading: and that is the TestNG provider. I don't yet have > an idea which way to go there. The current implementation requires all test > classes to be known upfront, in order for the provider to decide where to > store the test results: in case both JUnit and TestNG tests are present, > distinct directories will be created. Otherwise, they just land directly > test result directory. So it might have to be necessary to further > pre-process the test set in the parent process (which would require some > more API changes for the providers); to always hand over all the tests > known and to let each forked process somehow select a subset for the actual > execution; or maybe to decide that TestNG always uses special > sub-directories for JUnit results and TestNG result, regardless of whether > both types of test classes are present or not. (That currently unused > attribute multipleTestsForFork in ProviderConfiguration was meant to > somehow address the TestNG problem, but there's still some stuff to think > about first.) I wonder why we can't just always split them....? Did you actually try just running multiple times over & over ? > And, one more thing, the current code does not support the concurrent > execution of test classes within one process (the parallel option). But I > guess that threaded handling of the input in LazyTestsToRun would not make > a difference there, either. ;) However, it might go in a direction similar > to the TestNG thing. But I'd prefer to leave out combining the parallel > option with the *forkperthread options for now... :) I think we can live with that. Achieving full symmetry of options would be cool, but this stuff is also quite hard sometimes and the end-user gains questionable ;) Kristian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
