2012/11/7 Kristian Rosenvold <[email protected]> > 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 ;) >
Done :) > > > > > 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 ? > I think always splitting would be the best option, given that is actually an option, as it might confuse users. But then again... if you actually "run mvn test -Dtest=..." multiple times today, it would generate the output into one directory, regardless of the type of test I'm specifying. So in case mixing both output types is an issue, we would have that issue today already. Does anybody know why exactly the output directories are different in case both test types are in the test set? > > > 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 ;) > Then, while we're at it, how about cleaning up the forkMode options? As Kristian already suggested, there could be a new attribute "reuseFork" (boolean, default: true). We could eliminate forkMode and just have "fork" (boolean, default: false). Depending on the value of threadCount (default: 1), that would give us: * threadCount=1: + fork=false, reuseFork=<does not matter> --> today's forkMode=never + fork=true, reuseFork=true --> today's forkMode=once + fork=true, reuseFork=false --> today's forkMode=always * threadCount>1: + fork=true, reuseFork=false --> today's forkMode=perthread + fork=true, reuseFork=true --> forkMode=onceperthread + fork=false --> requires JUnit47 or TestNG and some setting of the parallel attribute? Or, we could leave forkMode=[never|once|always] (remove "perthread") and use the strategies perthread or onceperthread implicitly in case of threadCount>1 and forkMode=always or once (respectively). What do you think? Andreas
