geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: POP3 and IMAP support
Date Sun, 29 Jan 2006 16:02:31 GMT
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 <bruce.snyder@gmail.com> wrote:
>
> On 1/27/06, Davanum Srinivas <davanum@gmail.com> 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)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
>

Mime
View raw message