db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vemund Ostgaard <Vemund.Ostga...@Sun.COM>
Subject Re: Running the junit testsuite with a remote server
Date Tue, 18 Sep 2007 08:37:54 GMT
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

View raw message