commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: Adding TERMINAL-TYPE option to TelnetClient
Date Wed, 19 Mar 2003 09:19:21 GMT

In the enclosed file you will find some
JUnit test cases for the TelnetClient patch.
The test cases support the last version of the patch
(the one I sent on march 17th). I won't write test
cases for the previous alternative version unless we
decide that we want to apply that version of the patch.

You'll find three groups of test cases:

- Unit tests. These are for the new classes, without 
hitting the network (InvalidTelnetOptionExceptionTest,
SimpleOptionHandlerTest, SuppressGAOptionHandlerTest,
TerminalTypeOptionHandlerTest, EchoOptionHandlerTest.
- Protocol compliance tests. Finally, I implemented a
simple test server (TelnetTestSimpleServer) that is
used to do the  testing at the protocol level. It is
a very simple server that listens for connections in
an independent thread and can be controlled by the
outside for sending/receiving bytes. By the time,
this test hasn't got 100% coverage of telnet
protocol compliance. It covers to some extent option
negotiation and AYT processing. (TelnetClientTest)
- Functional test. It is a small functional test in
which TelnetClient is used to look for Los Angeles
weather forecast at

All the tests are JUnit, so you should be able to
automatically execute them, but they have some

- For the protocol compliance test, the simple server
listens on ports 3333, 3334, 3335. Make sure that
these ports are free.
- For the functional test, make sure that you can
reach the weather service
A major issue for this last test is that it expects
the serve sends some fixed strings. If in the
future is changed (for
example, more menus are added or prompts are changed)
the functional test won't be working anymore. Any
idea for a more robust funtional test will be
greatly appreciated!!

Law of testing: No matter how many tests you have done
before, any execution of a test suite comes out with
some bug. This case is no exception: Executing the
test cases I found two bugs:

- A bug in the option negotiation logic which was
already there in the original telnet client
(In case TC sends a DO, remote party refuses it
sending a WONT, TC didn't acknowledge with a DONT.
Simmetrically when TC sends a WILL, remote sends
DONT TC didn't acknoledge with a WONT).
- A bug in the new getLocalOptionState() and
getRemoteOptionState() API methods.

The bugs have been fixed by modifying
I enclose source code for the patch (all the sources
are included, patch + the two bug fixes)

View raw message