Daniel John Debrunner wrote:
Andreas Korneliussen wrote:
Daniel John Debrunner wrote:
[EMAIL PROTECTED] 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
