> -----Original Message----- > From: Daniel F. Savarese [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 20, 2002 10:02 AM > To: [EMAIL PROTECTED] > Subject: Re: [patch] NetComponents - FTPClient's restart functionality
[SNIP] > Testing any of the protocols is tough. One way is to provide a fake > server that reproduces the proper state transitions for each RFC. > This is easy to do by using setSocketFactory() to set a factory on > each client that produces a socket that creates input and output > streams to this state transition engine. However, once you go to > all of that trouble, you might as well write a bunch of full blown > servers. Therefore, it is best to test against some set of servers > that the developer trusts to be reasonably faithful implementations > of the RFC. These could be set in a property file and default to > test servers on the developers machine. So a restart unit test would > involve ftp'ing a known file, reading some random number of bytes > from it, closing the data connection, and then opening a new data > connection, restarting from the end of the local file. After the > transfer is complete, do a binary byte-for-byte comparison of each > file. But we ought to create some skeleton code or a base testing > class(es) that can be used as starting points for writing these > protocol tests. It may not be a bad idea to look at what HttpClient > does. This was an interesting article along some of the same lines: http://www.javaworld.com/javaworld/jw-07-2002/jw-0719-networkunittest.html It would be nice to have units tests that do not depend on external systems that run on each build. Another set of 'acceptance' tests such as the ones you describe above that do in fact access external servers is also needed. But don't get me wrong, having tests is better than no tests. > Jeff, I was in the habit of maintaining a CHANGES file that recorded > all of the major changes between each version of the software. > Autogenerated changelogs tend to get cluttered with a lot of > extraneous > stuff. What's the equivalent place to store this > information? I don't > want to reconstitute the changes from memory when people start asking > what changed between v1.3.8 and the first Jakarta release. Maven doesn't at this time provide this automatically, there's been some rumblings about it but nothing yet. How about we just start a changes xdoc that can become part of the site? ================================================================= Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
