db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject [junit] frameworks in Junit WAS Re: svn commit: r432569
Date Fri, 18 Aug 2006 16:51:47 GMT
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?

When run in the harness the network server is already started correctly
so won't this just try to start another server and fail?

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

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

java junit.textui.TestRunner
    org.apache.derbyTesting.functionTests.suites.AllJDBC

4) Run a single test (or suite) in a specified framework

How to do this? Could be system properties, e.g.

# Single test
java -Dframework=DerbyNetClient junit.textui.TestRunner
    org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest

# Single package suite
java -Dframework=DerbyNetClient junit.textui.TestRunner
    org.apache.derbyTesting.functionTests.tests.jdbcapi._Suite

# Suite of multiple packages
java -Dframework=DerbyNetClient junit.textui.TestRunner
    org.apache.derbyTesting.functionTests.suites.JDBC

Could be a Derby Junit test running, just used for this development purpose

# Run two tests using the Derby network client
java org.apache.derbyTesting.junit.DerbyClientRunner
    org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest
    org.apache.derbyTesting.functionTests.tests.jdbcapi.BLOBTest

# Run two tests using the DB2 client
java org.apache.derbyTesting.junit.DB2ClientRunner
    org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest
    org.apache.derbyTesting.functionTests.tests.lang.GrantRevoke


My gut feeling is relyin on system properties to drive behaviour from
the command line will led to tests that are hard to integrate into
suites of other projects.

Dan.


Mime
View raw message