commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jbre...@wi.rr.com (Jeffrey D. Brekke)
Subject Re: Adding TERMINAL-TYPE option to TelnetClient
Date Mon, 17 Mar 2003 17:52:01 GMT
>>>>> On Mon, 17 Mar 2003 17:58:43 +0100, "b.davanzo@inwind.it" <b.davanzo@inwind.it>
said:

> - 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.  

This sounds good.  Are you thinking of a junit TestCase that unit
tests would specialize or a set of mocks/stubs that test cases would
use as fixtures to setup different states?  I haven't dug into the
telnet code much, but it seems that we really want to test the state
machine given different protocol inputs?

There was an article about testing network level stuff, I think I
referenced it here on this list once, I'll see if I can find it.
( Unless someone remembers for me )

> - 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 r
> these tests.  

This sounds like what we want to achive above with the protocol tests
also.  I'm thinking we wouldn't need to hit the wire at all for these
types of tests.

> - We can use TelnetExample1 and TelnetExample2 with
> some existing server on the net (rainmaker.wunderground.com ?) to do
> the functional testing.

Agreed.

> 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.

I understand about being busy ;)  

> 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?

We should try to automate it.  We don't want to have manual tests if
we can help it.  If we have a lengthy setup of the testing environment
or need some kind of definitions for the functional tests, we could
use the apache wiki or add a document to the commons web site.

-- 
=====================================================================
Jeffrey D. Brekke                                   jbrekke@wi.rr.com
Wisconsin,  USA                                     brekke@apache.org
                                                    ekkerbj@yahoo.com


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message