geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: POP3 and IMAP support
Date Sun, 29 Jan 2006 18:30:57 GMT
I think an investment mock connection framework will really payoff in  
the long run.  As we find quarks in each mail server we can easily  
create a new connection which captures these quarks, and everyone  
will be able to test without have 10 mail servers setup.

-dain

On Jan 29, 2006, at 8:02 AM, Rajith Attapattu wrote:

> 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