This is the mail archive of the mauve-patches@sources.redhat.com mailing list for the Mauve project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gnu.testlet.java.net.Socket tests


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.

Bryce


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]