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 Mon, 17 Mar 2003 16:58:43 GMT
>I agree that testing at the protocol level would be needed and also a
>functional test against some existing servers.  Both types of tests
>are going to be useful.  Currently there are no tests, only some
>examples.  This is an area where commons-net really needs some polish.
>It may be difficult to write *unit tests* for the existing code, but
>functional tests might have to do instead.  But for new code (
>especially new classes ) we could start with unit tests that do not
>require external systems.  It is a difficult task to start out with,
>but one I think we need to start talking about at least.

>So any idea on getting a test harness for functional tests (
> / are what I'm currently using at work and
>seems to work well ) and/or staring with some small unit tests would
>be beneficial.  Maven is setup to fire junit based tests nicely and we
>have some unit tests for the line parsers for the ftp code already.


Thanks for the info.

If you agree we could go on this way:

- I'll try to have ready a simple server that is configurable enough for setting up different
test cases at the protocol level. It could be reused for testing all the TelnetClient protocol
compliance when someone has the time to accomplish the task of analyizing the part of telnet
protocol implemented by it and defining test cases for it. But... how do we ensure that the
"tester" server we use doesn't have some problem affecting the test results?. I'll try to
keep it as simple at possible, and it should be strongly reviewed to ensure that it is (almost)
bug free.
- For the unit testing, I think that it's possible only for classes whose behaviour does not
depend drammatically on the presence and behaviour of another party on a network (unless we
are able to use the same "tester" protocol server of the above point for unit-test the network
classes). So I think that we could do, by the moment, the unit test of the new classes (which
by themselves don't require a network partner to test, as they aren't accessing the network).
I'll look at Maven for these tests.
- We can use TelnetExample1 and TelnetExample2 with some existing server on the net (
?) to do the functional testing.

If you agree, I'll try to come out with the "tester" server in a couple of day... still busy
at work.. :-(
Also, I'll try to see how to do unit testing on TelnetOptionHandler, its derived classes and
InvalidTelnetOptionException by using Maven (which I haven't seen yet).
Regarding the functional test, I had a look at the examples, it should be enough. The examples
are simple terminals that allows you to connect to a server and, besides providing access
to the server, accept some commands that axercise the new APIs. Have a look at them and tell
me what do you think about, if you have the time for it.

Another point: how should we document the test procedure?
For example, it is likely that the functional tests should be run by a person which will follow
a test procedure looking for some desired test results. How do we document this?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message