You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by an...@apache.org on 2006/08/18 15:05:45 UTC
svn commit: r432569 -
/db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java
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. Removed import of ..functionalTests.util package.
Modified:
db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java
Modified: db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java?rev=432569&r1=432568&r2=432569&view=diff
==============================================================================
--- db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java (original)
+++ db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java Fri Aug 18 06:05:45 2006
@@ -25,10 +25,6 @@
import junit.framework.Test;
import org.apache.derby.drda.NetworkServerControl;
-// This import can be removed once junit classes are moved to this
-// package:
-import org.apache.derbyTesting.functionTests.util.*;
-
/**
* Test decorator that starts the network server on startup
* and stops it on teardown.
@@ -37,7 +33,7 @@
* embedded mode.
*
* Currently it will start the network server in the same VM
- * as, and it does not support starting it from a remote
+ * and it does not support starting it from a remote
* machine.
*/
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());
Re: [junit] frameworks in Junit WAS Re: svn commit: r432569
Posted by Andreas Korneliussen <An...@Sun.COM>.
>>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.
Regards
Andreas
> Thanks, I think we are making progress here.
> Dan.
>
>
Re: [junit] frameworks in Junit WAS Re: svn commit: r432569
Posted by Daniel John Debrunner <dj...@apache.org>.
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.
Re: [junit] frameworks in Junit WAS Re: svn commit: r432569
Posted by Andreas Korneliussen <An...@Sun.COM>.
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
[junit] frameworks in Junit WAS Re: svn commit: r432569
Posted by Daniel John Debrunner <dj...@apache.org>.
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.
Re: svn commit: r432569 -
/db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java
Posted by Andreas Korneliussen <An...@Sun.COM>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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))
}
Alternatively, I could move the check to the suite() method:
jdbcapi._Suite.suite() {
..
suite.addTest(ConcurrencyTest.suite());
suite.addTest(..);
..
if (isEmbedded) {
return suite
} else {
return new NetworkServerTestSetup(suite))
}
}
I would also need to disable starting of network server from the harness
for the _Suite test.
Andreas
> Dan.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (SunOS)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE5dc936DpyYjYNyIRAu67AKDJ/96f1NqWIjYdAOGoJzJtYwfk+QCdEVRL
5HebJuZtQtqgYBroFJQaKUo=
=u76I
-----END PGP SIGNATURE-----
Re: svn commit: r432569 - /db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java
Posted by Daniel John Debrunner <dj...@apache.org>.
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?
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()));
Dan.