In *addition to* the "RFC-compliance" tests, it seems necessary to me (especially looking forward to IMAP, where real-world client compliance may not be as strict as with POP3) to have some sort of "session-recorder" that would make recording new scripts from real-world clients almost trivial. I've been looking at building such a recorder using a modified packet sniffer:
1) tcpflow is an extension to tcpdump that writes data portion of all filtered packets to file. (*nix only)
2) jpcap is a java wrapper for libpcap/tcpdump that would allow us to capture sessions from both Windows and *nix machines.
I'm thinking that I could use 2) to build a recorder to create the (C: blah S:blah) test scripts that we're currently using. Does this sound helpful to others?
Jmeter has a similar "recording" feature built on a simple local proxy, but it's a bit painful to turn the proxy on/off and change your browser settings every time you want to record. Thoughts?
Nathan
Noel J. Bergman wrote:
I have looked at some of the recent posts, and get the sense that the test scripts are ad hoc. It seems to me that we ought to adopt a more formal methodology, develop a test strategy, and base the initial majority of scripts on testing for compliance with the RFCs. Additional scripts can be based upon specific needs, e.g., accommodating real-world compatibility with specific applications. We should have documented scripts that explain what the standard is, what any special deviation(s) might be, what is being tested, and why.For these "telnet-based" protocols, I believe that we can (and should) leverage regular expressions, rather than just plain canned strings for comparing. That way we can better handle response strings, and use data from matched groups within our following commands. I am also of a mind that we should look at using BSF as a key component of our testing framework. That would let us leverage simple templates as well as more complex scripts, including those adapted from other suites. Harmeet mentioned Python, which can be used with BSF: http://www.lonsteins.com/articles/jython-bsf.html. Done properly, this becomes a very useful general purpose test bed, customized for a given protocol by additional beans and scripts. Lastly, we needn't have an NIH approach to this sort of external testing. I am sure that we can find other tests to supplement those that we build. Thoughts? --- Noel -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
-- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
