commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Jeffrey D. Brekke)
Subject Re: Adding TERMINAL-TYPE option to TelnetClient
Date Mon, 31 Mar 2003 02:35:08 GMT
>>>>> On Sun, 30 Mar 2003 20:01:27 +0200, "" <>

> Maybe converting the examples to documentation is the best thing to
> do.  Alternatively, I could modify the TelnetClientExample3 to
> output the spy on a file instead of waiting a second telnet
> connection and spying the primary connection on the second
> connection as it does at the moment.  What do you think about?

Writing to a file sounds reasonable for the example.  If you want to
add documentation that would also be great.  Maybe a how-to or faq of
sorts.  You could just provide xdocs or use the apache wiki.

> what should the test do in case an I/O exception occurs?  (throw the
> exception, catch it silently...?) I mean, how is it normally managed
> an error condition in the test?  I'll try to restructure
> TelnetClientTest not to do so much in the setUp().

The general convention when there is an error condition that the test
is not testing for is to let the exceptions fly.  Junit will
ultimately catch all the exceptions and report it as an *error* and
not a *failure*.  Generally I don't catch exceptions in my test cases
unless I'm explicitly testing for the throwing of an exception.
>> * The code style conventions should be followed. ( minor )
> Could you be more specific? I tried to keep up to the standard
> coding style used in commons net, which is fairly low :-). I'll try
> to add javadoc comments to each new class and method, but I don't
> have the time to fully comment the code...

I know there are violations in the current code base, the checkstyle
report shows that.  But for new stuff we should try to stick to the
above standard when possible and verify with checkstyle.

>> The functional tests are nice to see in there, but I suppose we'll
>> need to find out a way to skip them at compile time for users who
>> build but don't have access to get to the internet.

> Two solutions for TelnetClientFunctionalTest:

> 1) we could try to skip it if you don't have connection to the
> internet, but in this case it would be a test that is always
> succeeding!

I think that the running of the fuctional tests could require a
connection to a real server over a network.  I just think that the
build shouldn't depend on the functional tests.  This is something
that I've been wanting to add to Maven for some time.  An additional
goal for functional tests so they can be removed from the normal
*unit* test run that happens at each build.

I was thinking of just a different goal, like maven test:ftests or
something.  For now I suppose we could exclude the tests that require
the net and just provide directions to run single tests with maven to
run those that require the net.

I'll still take a look at the tcpspy stuff as I get time.  Thanks again.


Jeffrey D. Brekke                         
Wisconsin,  USA                           

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

View raw message