No. But at least we need to test the behaviour of ServerSocket(fixed port)
constructor once. For example, if I implemented ServerSocket(int port) as
follows:
public ServerSocket(int port) {
port = 0;
// no matter what the port is, the constructor always constructs a
server
socket with free port
}
It's obviously wrong, but can any test detect this error?
I could suggest something like this:
ServerSocket ss = ServerSocket(0);
int fixedPort = ss.getLocalPort();
ss.close();
ServerSocket ssUnderTest = new ServerSocket(fixedPort);
// test if opened ServerSocket listens on port "fixedPort"
// even if SS is set the port internally to 0 - this code will find the bug
:-)
Yes, yes - i could guess your argument "What if first SS not actually close
the connection but reuse it?" :-).
Well - let's consider this as one of 2 axiom:
1) ServerSocket(0) really choose non-busy port (BTW, this is not tested in
ServerSocketTest at all, but i do understand that this is hard to test)
2) close() method really close an open SS (this assumption is tested by
ServerSocketTest.test_close() method).
Also, for example, ServerSocketTest.test_ConstructorII() calls
getNextPort() 3 times, so we need either to reserve 3 ports for testing or
reuse 1 port 3 times. Thoughts?
Regards,
Mikhail
On 12/26/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
On 12/25/06, Mikhail Markov <[EMAIL PROTECTED]> wrote:
>
> Thank you for your warm words!
>
> > But without fixed port meaning that we never test the behaviour of
> > ServerSocket(1000).
> > That's why I suggest to introduce fixed port for ServerSocket
> constructor
> > test.
> > My suggestion is not to discard your patch, but using your patch +
fixed
> > port to replace current getNextPort machenism. Does it make sense?
> Thanks!
> Why my approach does not work in this case?
> For example:
> void test_ServerSocketCosntructor() {
> ...
> int port = getNextPort(); // got free port number
> ServerSocket ss = new ServerSocket(port);
>
> // tests ServerSocket opened on fixed port here
> // checks if ServerSocket listens on this port etc.
> ...
> }
> Or testing ServerSocket each time on the same port number is critical?
No. But at least we need to test the behaviour of ServerSocket(fixed port)
constructor once. For example, if I implemented ServerSocket(int port) as
follows:
public ServerSocket(int port) {
port = 0;
// no matter what the port is, the constructor always constructs a
server
socket with free port
}
It's obviously wrong, but can any test detect this error?
Regards,
> Mikhail
>
> On 12/25/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> >
> > On 12/25/06, Mikhail Markov <[EMAIL PROTECTED]> wrote:
> > >
> > > > Hey Mikhail, I think I have agreed with all your words in my
> previous
> > > > letter. We've agreed to use port 0 for most network tests. Fixed
> port
> > > number
> > > > is required sometimes, i.e., how do you write test for
> > ServerSocket(int
> > > > port)?
> > > Sorry, Andrew - I did not participated in original discussion and
> Alexei
> > > in
> > > http://issues.apache.org/jira/browse/HARMONY-2338 said that he
> > > understands the final decision as we will use reserved ports numbers
-
> > so
> > > I've decided to re-check once again.
> > >
> > > > We'd better test ServerSocket constructor with both legal
value(not
> > > > only 0, but also some positive numbers), and illegal value. That's
> > where
> > > > fixed port number is used. Make sense? Thanks!
> > > Why not use ServerSocket(0) to just *obtain* some positive non-busy
> port
> > > number (and close it after port number obtaining) and after that
test
> > > ServerSocket constructor with this obtained port number? In this
case
> > > we'll
> > > not require any reserved ports at all.
> > > I've implemented this approach and attached the patch - could you
> please
> > > take a look at it?
> >
> >
> > Hi Mikhail, the patch is good! I agree that it's a good fix as always.
> :-)
> > But without fixed port meaning that we never test the behaviour of
> > ServerSocket(1000).
> > That's why I suggest to introduce fixed port for ServerSocket
> constructor
> > test.
> > My suggestion is not to discard your patch, but using your patch +
fixed
> > port to replace current getNextPort machenism. Does it make sense?
> Thanks!
> >
> > Thanks,
> > > Mikhail
> > >
> > >
> > > On 12/24/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On 12/24/06, Mikhail Markov <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > I still don't like using fixed port numbers. Moreover, some
tests
> > > might
> > > > > require several ports for testing.
> > > > > I did not see any objections against using 0 as a port number,
> > except
> > > > that
> > > > > some functionality should be tested with fixed port numbers.
> > > > > How about the following scheme for *finding* non-busy port:
> > > > > 1) invoke ServerSocket(0) constructor
> > > > > 2) get the port where ServerSocket opened the socket
> > > > > 3) close ServerSocket
> > > > > 4) use the stored port from 2-nd step for further testing (it
> could
> > be
> > > > > Socket/ServerSocket/nio tests etc.)
> > > > >
> > > > > What do you think?
> > > >
> > > >
> > > > Hey Mikhail, I think I have agreed with all your words in my
> previous
> > > > letter. We've agreed to use port 0 for most network tests. Fixed
> port
> > > > number
> > > > is required sometimes, i.e., how do you write test for
> > ServerSocket(int
> > > > port)? We'd better test ServerSocket constructor with both legal
> > > value(not
> > > > only 0, but also some positive numbers), and illegal value. That's
> > where
> > > > fixed port number is used. Make sense? Thanks!
> > > >
> > > > Thanks,
> > > > > Mikhail
> >
> >
>
>
--
Best regards,
Andrew Zhang
