db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: [junit] frameworks in Junit WAS Re: svn commit: r432569
Date Fri, 18 Aug 2006 19:32:20 GMT

>>It won't fail, since the the harness won't start it when
>>_Suite_app.properties contains a property to not start it.
> My intention with my current set of work for JUnit is to divorce the
> JUnit tests from the existing harness and have them be able to run
> standalone. Any time we add dependencies back to the harness, e.g. a
> _Suite_app.properties file then that goal gets harder. Maybe it's ok in
> this case, because it's really a step towards the divorce by relying
> less on the harness (ie the test starts the server itself). I would just
> encourage everyone to consider carefully before they add _app.properties
> files for JUnit tests.

Yes, that was my intention too: avoid adding _app.properties for 
ConcurrencyTest. Therefore I wanted to use SystemPropertiesTestSetup and 
  also the new NetworkServerTestSetup (to make SystemPropertiesTestSetup 
have relevance in network frameworks).

>>I think the new decorator simply builds on what is currently present: TestConfiguration.
Each BaseTestCase has a TestConfiguration (currently it is a final static, immutable singleton,
and configured from system properties). Therefore, within one VM we only support one framework
(in TestConfiguration).
>>I think what you wish is to be able to run multiple tests with different frameworks
(all frameworks) within the same VM. To do that it is necessary to look into the way Testconfiguration
is being used, and possibly how suites are being created. 
> Yes, that's my plan.
>>Yes, except I am a bit worried about
>>java junit.textui.TestRunner
>>     org.apache.derbyTesting.functionTests.suites.All
>>I'd rather see it run all suites in one framework specified on commandline, than in
trying to figure out which frameworks are availabe on the classpath (i.e db2client etc). 
> I'm not clear on your concern here. Could you be more explicit?
> I do believe there should be an option to run all tests in a single
> framework, but I also think there should be a suite that matches what
> derbyall is today.

Agreed - my concern was that the derbyall replacement test would need to 
analyze the classpath in order to figure which tests to run. Today, I 
think RunSuite does that when running derbyall. Not really a big concern.


> Thanks, I think we are making progress here.
> Dan.

View raw message