On Mon, Mar 15, 2010 at 1:10 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: > I would also like to see a more aggressive testing strategy, probably using > 'once' instead of 'pertest'. The only major offender is indeed jmx which > does not cleanup properly on shutdown, you are correct. We should definitely > look into the jmx cleanup, because we cannot always assume the lifetime of > the camel context to match the one of the hosting process. >
No I dont think this is a good way. We end up with having unforseen side effects which causes all kind of pain trying to look into it and thinking there is a real problem. I would suggest if its possible with Maven to have a profile for testing without "per test" that people can run if they like to run a faster test, but with the potential of unforseen sideeffects. Then all the CI servers can chunk using per test and have a longer but reliable test run. > My $0.02, > Hadrian > > On Mar 15, 2010, at 3:33 AM, Christian Schneider wrote: > >> Hi Willem, >> >> that is probably a good idea. I guess there are other modules that need this >> setting too. I can report where I have failures now and you can then also >> set these modules to fork per test. >> Many modules like core and spring do not seem to need the setting. So I >> guess it is a good idea to keep the fork mode in a faster setting for them. >> >> Another possibility would be to set fork per test as default and set to a >> faster setting for specific modules. I guess Claus would prefer this variant. >> >> Greetings >> >> Christian >> >> >> Am 15.03.2010 07:41, schrieb Willem Jiang: >>> The test became long because I changed the surefire plugin's fork mode to >>> be "pertest" from the camel root pom.xml. That is not necessary for most >>> case, so I reverted my change and let the camel-jetty module's fork mode to >>> be "pertest". >>> >>> Willem >>> >>> Claus Ibsen wrote: >>>> On Mon, Mar 15, 2010 at 3:15 AM, Willem Jiang <willem.ji...@gmail.com> >>>> wrote: >>>>> Hi, >>>>> >>>>> I just change the fork mode in the camel-jetty to be pertest, it will save >>>>> us some time of running the test. >>>>> >>>> >>>> Why did you do that? Testing camel-jetty does not take that long. >>>> I would rather have a more stable and reliable build and test, than >>>> something that in some mysterious ways have errors which are caused by >>>> some side effects. >>>> >>>> I would like it to be reverted. >>>> >>>> >>>>> Willem >>>>> >>>>> Christian Schneider wrote: >>>>>> Am 14.03.2010 10:42, schrieb Claus Ibsen: >>>>>>> Great this is good news. You can really get on a wild goose chase if >>>>>>> testing is done without forking the JVM. >>>>>>> >>>>>>> The bad news it takes much longer to test. >>>>>>> Well it does not take around 150 min to do a full build on my Mac. It >>>>>>> used to be 120-130 min. >>>>>>> >>>>>>> >>>>>> Yes I also noticed the build takes longer now (about 240 minutes on my >>>>>> notebook). Perhaps the fork per test can be switched to a more moderate >>>>>> setting >>>>>> where we know the tests will work anyway. There is another thing I also >>>>>> noticed. The fork per test hides some unclean shutdown sequences where >>>>>> not >>>>>> all >>>>>> things are cleaned up. But I guess these could also be tested explicitly >>>>>> which is cleaner anyway. An example are the JMX tests which failed >>>>>> without >>>>>> the fork. >>>>>> I did not look into it in detail but I guess the JMX beans are not >>>>>> completely cleaned up on shutdown. Still I think it is a good thing that >>>>>> the >>>>>> build runs stable now. >>>>>> >>>>>> Greetings >>>>>> >>>>>> Christian >>>>>> >>>>> >>>> >>>> >>>> >>> >>> >> > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
