Likewise, you can drop a testng dependency in and have it run your junit 3.8 tests in parallel. I remember testing this very early on in the testng/surefire support.
I'd rather we didn't duplicate the parallel execution capabilities that are already present in the various testing libraries. On 16/01/2010, at 3:57 AM, Kristian Rosenvold wrote: > If you are running java5 or higher, there's a good chance you can just > drop in surefire2.5 and junit-4.8.1, without making any code changes at > all. Although I haven't tested this specifically, I think it should > work. > > You can read about how to do it here - I'll try to get parts of it into > some official documentation once I get the karma and find out where ;) > In the meantime there's only the javadoc in the plugin. > > http://incodewetrustinc.blogspot.com/2010/01/run-your-junit-tests-concurrently-with.html > > Kristian > > > On Fri, 2010-01-15 at 16:39 +0000, Colm O'Donnell wrote: >> Thanks for your prompt response. >> >> We are using junit 3.8 unfortunately. We will look at upgrading >> version but this patch will work with no upgrades to junit. >> >> On 1/15/10, Stephen Connolly <[email protected]> wrote: >>> Eh.... Surefire 2.5 (which is in the process of being released) >>> supports the parallel execution features of JUnit 4.7+ >>> >>> If that works for you, no patch required >>> >>> -Stephen >>> >>> 2010/1/15 Colm O'Donnell <[email protected]>: >>>> Hi, >>>> >>>> I work for a company that have a large number of junit tests. We have >>>> migrated from ant to maven recently but are faced with a serious problem >>>> with respect to the time to execute the tests. We used to execute some >>>> tests >>>> in parallel with ant but it was not great and depended on a lot of manual >>>> effort. Currently we have to disable surefire and revert to calling ant to >>>> execute the tests. >>>> >>>> We have attempted to patch surefire to allow for parallel execution of >>>> Junit >>>> tests. And we are wondering if we could submit a patch for this. It >>>> required >>>> some small refactorings of the surefire booter classes to create a >>>> different >>>> implementation of an interface for each type of booting available . e.g. >>>> move the content of the method runSuitesInProcess into a class in its own >>>> right. >>>> >>>> It reuses the existing booter functionality to spawn processes and adds >>>> another for threaded execution. >>>> So there exists a new class available to booter can scan the test dir and >>>> find out the number of tests and then divide them up into a configurable >>>> chunk size and hands chunks of tests to the implementation for the >>>> selected >>>> concurrency mode. >>>> >>>> Would this approach to sure fire be acceptable? >>>> And where do I submit our patch? >>>> >>>> >>>> Cheers >>>> >>>> Colm >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Brett Porter [email protected] http://brettporter.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
