Myrna van Lunteren wrote:
Starting to reason from the tests, I think part of the issue is that
there are tests that test the correct starting and shutting down of
the network server; or that need the server to be started with
specific properties as opposed to the 'normal' mode. And as far as I
know we cannot start and shutdown a server on a remote machine, and
thus these tests cannot run with a remote server.
So there is a group of tests that can only be run with the server on the
localhost and/or only make sense to run with the server on the localhost.
Probably there is also a group of tests that only make sense to run with
the server on a remote machine, for instance verifying that you are not
allowed to shut it down?
Finally there is the group of tests that make sense to run both with a
remote server and with a local server, and possibly also in embedded mode.
Theoretically, all tests that do not need to test starting/shutting
down, or that do not test the server with specific properties set,
should, be 'runnable' with remote server that is already running.
However, is that really necessary? What things could go wrong when
connecting to a remote server versus a server on localhost? I would
think mostly things to do with connections, permissions,
import/export. So, maybe it makes sense after all to have a dedicated
set of tests for remote server testing.
From reading about the junit tests on the wiki and taking a look at the
code, I understand that the logic for controlling which test fixtures
are run with an embedded database and which fixtures are run with a
network server, is in the suite() method of the various test classes. I
guess this is the right place to put logic that will
Note that with remote server testing, trouble brews in the area of
cleanup; I believe the current junit framework attempts to delete
files that get created by the server; and I think deleting of files on
a remote machine should be impossible. I wasted considerable time with
the old test harness trying to identify tests that would run cleanly
in sequence; only to find that a previously working set was made to
fail because a uncooperative test/testcase was added. It may be better
to create a suite of tests, normally part of suites.All, which
can/should be run against a remote server as well.
For the desire to be able to run all client tests; that is more an
efficiency issue useful for someone working on client only changes;
when one is certain there is no need to run the tests with embedded. I
think maybe a class that travels through the test suites and
identifies the ones that run with DerbyNetClient would cover that
requirement. The converse could also be true (run only embedded
tests), but I believe this can be achieved by excluding
derbyclient.jar from the classpath.
I have a hard time to imagine how to arrange for a configurable port
number and host without using properties in some manner. But I imagine
some default values, and/or a scheme to identify existing servers
running could be devised. Maybe someone else has good suggestions.
Myrna
