This is the mail archive of the
mailing list for the Mauve project.
Re: gnu.testlet.java.net.Socket tests
- From: Bryce McKinlay <mckinlay at redhat dot com>
- To: Stephen Crawley <crawley at dstc dot edu dot au>
- Cc: mauve-patches at sources dot redhat dot com, crawley at piglet dot dstc dot edu dot au
- Date: Thu, 10 Feb 2005 00:33:56 -0500
- Subject: Re: gnu.testlet.java.net.Socket tests
- References: <200502100449.j1A4n6N3021864@piglet.dstc.edu.au>
Stephen Crawley wrote:
This patch changes them to start their own local server in another thread.
In effect, you have turned this test into a testcase for both the
client AND server sides of the VM / Classpath's socket support. This
is a bad idea, IMO.
That is true, it is certainly desirable to keep the scope of test cases
to a minimum where possible. However, it is not possible to test every
runtime feature in isolation. Every test case relies on or assumes that
at least some other runtime functionality is working. I think that in
this case, setting up a server socket to test client socket
functionality is not unreasonable.
It would be better to make the target hostname and/or port number
configuration parameters. Ideally, the ./configure script should be
able to intuit sensible settings and/or allow the user to override them
via a '--with' option.
I really want to avoid doing something like that, because the test-suite
should be zero-configuration wherever possible. It can already be a PITA
to configure and run mauve, and we don't want to make it worse. There's
no way I want to find and configure a remote server for socket tests on
every machine I might want to do a mauve run on! If we must have test
cases that require configuration, in cases where its unavoidable, then
those tests should be set up so as to only run when the configuration
has been set, and should be ignored in the default configuration.
Unfortunately I don't think its possible to come up with a sensible
default for a server that is always going to be reachable behind
firewalls and such. Relying on external servers for test cases to
function also introduces the possibility of spurious failures due to
network problems. Plus, I don't think that relying on some very basic
Thread and ServerSocket functionality working is any worse than relying
on some remote server connection.