Jeffrey, 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 rainmaker.wunderground.com (TelnetClientFuntionalTest). All the tests are JUnit, so you should be able to automatically execute them, but they have some requirements: - 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 rainmaker.wunderground.com. A major issue for this last test is that it expects the serve sends some fixed strings. If in the future rainmaker.wunderground.com 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 Telnet.java and TelnetClient.java I enclose source code for the patch (all the sources are included, patch + the two bug fixes) Bye, Bruno
commons-net-openoption-patch3.zip
Description: Zip compressed data
commons-net-openoption-patch3-test.zip
Description: Zip compressed data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
