Bruce,
I agree that my excuse for not writing unit tests is lame :)
With mock objects we should be able to cover a reasonable amount of code for atleast the trivial test cases. Ex. A MockPOP3Connection that returns a predetermined response that we can compare in an assert statement.
But as u said nothing can be substituted for integration testing. What I suggest is that maybe we should write a sample application that connects to a mail server and sends and reads emails . Intersted parties will run that to test with there own environment.
We should allow all values to be configured ( preferably via a GUI interface) so that they can customize it for their own environment.
The advantage of this approach (if we have under examples) is that the end users will also have a go. And obviously report on the user list if something is wrong.
Having said that I know we still cover only the basics with authentication (Rick has made some progress on this end). so once we cover a reasonable subset of auth mechanisms then we can
publish this sample application.
Till then lets use it among us.
Regards,
Rajith.
On 1/27/06, Bruce Snyder <[EMAIL PROTECTED]> wrote:
On 1/27/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> http://james.apache.org/?
James can certainly be used for testing POP3 and SMTP, but it does not
yet offer full IMAP support.
> > > One of the problems with POP3 (or SMTP) tests is the dependency on a
> > > mail server for running the tests. I've not figured out how to set
> > > things up to allow for that. Authentication tests are particularly
> > > difficult, since each type of authentication may require changing the
> > > target server configuration.
Please bear with me for a moment while I rant about my take on testing
in order to address the statements above.
<soapbox>
Testing comes in many forms, two of which often get lumped together:
unit testing and integration testing. IMO, these two types of testing
are distinct and serve two very different purposes.
Unit testing deals with the concept of tests that are completely
self-contained, do not require external systems and services ( e.g.,
databases, mail servers, etc.) and can be executed extremely fast
(i.e., seconds). Unit tests are often run during the build process
because of these characteristics which allows a large amount of these
tests to be run in a very short amount of time.
Integration testing is the exact opposite of unit testing. Integration
testing deals specifically with the concept of integrating with other
external systems and services. Because of this, integration tests
often take a much longer time to run (i.e., minutes) and should *not*
be run during the build process. These tests require a separate
process for running and should not be run for the standard build
process.
</soapbox>
Thanks for reading this far! I applaud you sticking with me through my
soapbox moment ;-).
One of the most difficult situations with unit testing is usually
encountered when writing test cases for code that requires an external
system or service. To address this need, I usually turn to EasyMock
(http://easymock.org/). EasyMock is a mocking framework that creates
mock objects for classes and interfaces on-the-fly through the use of
Java proxies. Because we're still using Java 1.4x with Geronimo,
EasyMock 1.2 will need to be used. When I first began using EasyMock,
without any knowledge of it, I was able to mock a persistence layer in
a sizeable application that required Oracle in a single afternoon.
Unit tests should be able to cover everthing in the JavaMail APIs that
we're creating from end-to-end. But unit tests are no substitution for
integration tests. It's extremely important to also write integration
tests that can be run against all of the most popular mail servers.
Without these, there's no way to guarantee that we're playing nice
with those mail servers.
I first thought about setting up a separate mail server on one of the
gbuild.org machines that can be used solely for testing the JavaMail
impl. One big issue with this strategy is that with multiple people
using the same mail server, we're bound to clobber one another's work.
Because of this, I abandoned the idea of setting up a mail server on
gbuild.org in favor of each of us setting up our own mail servers in
our own environment. In my situation, I'm setting up Postfix
specifically for testing on one of my machines.
Becoming experts on mail servers is one of the tasks we take on in
writing the JavaMail impl. That will most certainly require specific
configurations and customizations to situate the tests. Maybe we
should loosely agree to each use a different mail server just to cover
our bases. At any rate, all custom configurations will need to be
documented for each mail server to allow others to jump in if
necessary.
If you've read this far you deserve a trophy! Thanks for listening to
my ranting. Now I expect others to shoot holes in my arguments in
order to find an ideal solution.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo (http://geronimo.apache.org/)
Castor (http://castor.org/)
