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 18:36:10 GMT
Daniel John Debrunner wrote:
> Andreas Korneliussen wrote:
> 
> 
>>Daniel John Debrunner wrote:
>>
>>
>>>>andreask@apache.org wrote:
>>>>
>>>>
>>>>
>>>>>Author: andreask
>>>>>Date: Fri Aug 18 06:05:45 2006
>>>>>New Revision: 432569
>>>>>
>>>>>URL: http://svn.apache.org/viewvc?rev=432569&view=rev
>>>>>Log:
>>>>>Fixed bug in setUp causing it to only start server when running in embedded
mode.
>>>>
>>>>>final public class NetworkServerTestSetup extends TestSetup {
>>>>>@@ -57,7 +53,7 @@
>>>>>     */
>>>>>    protected void setUp() throws Exception {
>>>>>        
>>>>>-        if (config.getJDBCClient().isEmbedded()) {
>>>>>+        if (!config.getJDBCClient().isEmbedded()) {
>>>>>            BaseTestCase.println("Starting network server:");
>>>>>            networkServerController = new NetworkServerControl
>>>>>                (InetAddress.getByName(config.getHostName()), config.getPort());
>>>>>
>>>>
>>>>Why is the check for isEmbedded even there?
>>>>
>>
>>
>>As it is now, I need the check of isEmbedded() somewhere. Either in
>>NetworkServerTestSetup, or in the jdbcapi._Suite.suite() method.
>>
>>
>>
>>>>Wouldn't a test or a suite installing this decorator indicate that the
>>>>network server needs to be started? Not saying it's wrong, I'm just
>>>>trying to understand how it would be used. I was assuming that this
>>>>decorator would only be used outside of the existing harness, or inside
>>>>the harness only for tests that only run in network server mode.
>>>>
>>>>E.g. I was imanging a top level JUnit suite AllJDBC that would include
>>>>the jdbcapi._Suite and jdbc40._Suite like this.
>>>>
>>>>  suite.add(jdbcapi._Suite.suite());
>>>>  suite.add(jdbcapi._Suite.suite());
>>>>
>>>>  suite.add(new NetworkServerTestSetup(jdbcapi._Suite.suite()));
>>>>  suite.add(new NetworkServerTestSetup(jdbc40._Suite.suite()));
>>>>
>>
>>
>>Then NetworkServerTestSetup would also need a mechanism to tell the
>>underlying test(s) that they should use network driver instead of embedded.
>>
>>The way I was planning to use NetworkServerTestSetup, right now, was to
>>have :
>>
>>jdbcapi._Suite.suite() {
>>   ..
>>   suite.addTest(ConcurrencyTest.suite());
>>   suite.addTest(..);
>>   ..
>>
>>   return new NetworkServerTestSetup(suite))
>>}
> 
> 
> I'm lost here trying to understand what that achieves, adding the
> network server test setup decorator?
>

I want to run the test ConcurrencyTest with a set of properties for the 
derby database to reduce lock timeout. I add SystemPropertiesSetup(..) 
around the test to set the system properties, however that will only 
work in embedded mode, unless of course I also run the network server in 
the same vm. Therefore additionally having NetworkServerTestSetup helps 
achieving this.

> 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.

> When run in a Junit test runner the that decorator will do nothing (I
> think).
> 

It will start the network server when run in any frameworks except 
embedded. That way, you may be able to run tests in DerbyNetClient 
framework in standard Junit test runners without manually starting the 
network server, or depending on the harness to do it.

> I think the decorator you've added is useful but I think how different
> frameworks are handled when just running using JUnit test runners needs
> some planning. I've been thinking about it, but not sure of the correct
> approach. <....

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.


>...    Seems to me it should be based upon requirements of
> developers, which I think are:
>
> 1) Run the whole suite in all frameworks without having to specify any
> options. I think this should be something like:
> 
> java junit.textui.TestRunner
>     org.apache.derbyTesting.functionTests.suites.All
> 
> or (as well)
> 
> java -jar test/derbyTesting.jar
> 
> 2) Run all the tests relevant to a single area, e.g. store, language,
> jdbc in embedded, e.g.
> 
> java junit.textui.TestRunner
>     org.apache.derbyTesting.functionTests.suites.JDBC
> 
> java junit.textui.TestRunner
>     org.apache.derbyTesting.functionTests.suites.Language
> 
> java junit.textui.TestRunner
>     org.apache.derbyTesting.functionTests.suites.Store
> 
> 3) Run all the tests relevant to a single area, across all frameworks
> 
> Does this make sense?
> 

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).

Andreas

Mime
View raw message