|
From: Colin S. <col...@ex...> - 2004-07-17 02:18:46
|
It would still be nice to get all or most of the tests working in Eclipse again, but it'll have to wait a while. In the meantime, it's reasonable to run tests individually in Eclispe while writing code, and then run everything from ant right before checking in to make sure nothing's broken. Colin Thomas Risberg wrote: > Colin, > > This is excellent. It seems like I can run the tests faster than I > can type this email :-) The failing JUnit tests within Eclipse were > starting to bother me and testing with Ant was too slow. Now the Ant > tests take only 10% extra compared to running within Eclipse. > Definitely worth the upgrade!!!! Thanks for figuring this out. > > Thomas > > Colin Sampaleanu wrote: > >> I spent a bit more time and got this going. Running the "tests" >> target from command-line went down for me from about 6:40 to 1:37. >> Note bad! >> >> To get things going, I set the <junit> element forkmode to >> 'perBatch'. Then I excluded the 3 tests from the main <batchtest> >> element, and added them as 3 separate single test <batchtests> (still >> kept as <batchtest> instead of <test> so the default excludes would >> still work. It's not that great to have to name tests individually >> like this, but it's just a few. If this has to be done for a few >> more, it will actually get less verbose to just use a separate junit >> task instance, then one instance would have forkMode="perBatch", and >> one forkMode="perTest" (the default). >> >> Regards, >> Colin >> >> Colin Sampaleanu wrote: >> >>> Ant 1.6.2 is out, and with it support for a forkmode="once" on the >>> junit task, which allows ant to still fork for junit tests, but only >>> once for the entire task (instead of for each testcase). >>> Alternately, forkmode="perBatch" allows forking once per batch element. >>> >>> This is pretty promising, since it could bring the time to run the >>> test suite from ant down to a similar value to when running in an >>> IDE, which is currently much faster. >>> >>> I've tried to give it a go (making sure to remove the ant 1.6.1 in >>> the lib dir, otherwise that will interfere), by adding >>> forkmode="once" to the junit element in the tests target. It is >>> currently breaking on SqlStateExceptionTranslatorTests, due to the >>> initial context factory builder already being set. This should be >>> resolvable by using a separate batch for that test, or some other >>> strategy. I am curious however why this doesn't break in the IDE >>> though. >>> >>> I don't have time to play with this any longer, but will give it a >>> go at some later date. If anybody feels like playing around with >>> this themselves, please go ahead by all means. >>> >>> Regards, >>> Colin >>> >>> ----- >>> >>> [junit] Testsuite: >>> org.springframework.jdbc.support.SQLStateExceptionTransla >>> torTests >>> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0 sec >>> >>> [junit] Testcase: testBadSqlGrammar took 0 sec >>> [junit] Testcase: testInvalidSqlStateCode took 0 sec >>> [junit] Testcase: testMalformedSqlStateCodes took 0 sec >>> [junit] java.lang.ExceptionInInitializerError >>> [junit] at java.lang.Class.forName0(Native Method) >>> [junit] at java.lang.Class.forName(Class.java:141) >>> [junit] at >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >>> <init>(JUnitTestRunner.java:204) >>> [junit] at >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >>> <init>(JUnitTestRunner.java:177) >>> [junit] at >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >>> launch(JUnitTestRunner.java:651) >>> [junit] at >>> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. >>> main(JUnitTestRunner.java:537) >>> [junit] Caused by: java.lang.IllegalStateException: >>> InitialContextFactoryBui >>> lder already set >>> [junit] at >>> javax.naming.spi.NamingManager.setInitialContextFactoryBuilde >>> r(NamingManager.java:687) >>> [junit] at >>> org.springframework.jms.JmsTestCase.<clinit>(JmsTestCase.java >>> :93) >> |