Andreas Korneliussen wrote: > Daniel John Debrunner wrote:
>> When run in the harness the network server is already started correctly >> so won't this just try to start another server and fail? >> > > 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. > 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. Thanks, I think we are making progress here. Dan.
