james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darrell DeBoer" <li...@bigdaz.com>
Subject Re: Working on IMAPServer (and other things)
Date Sun, 06 Jan 2002 21:18:08 GMT
G'day

> >Does anyone have a set of tests which could form the starting point for a
> >full set of functional tests? I imagine that a bunch have been written in
> >the process of developing/testing the SMTP and POP servers.
>
> POP and SMTP functionality are easily tested using telnet, I suspect this
> has made me (at least) complacent.. good tests of basic function would
> indeed be worthwhile.

I'm allergic to manual testing :)
As part of my IMAP work, I've developed a simple "protocol testing
framework" (as JUnit tests), which allows tests to be defined as text files
of the format:
C: <client-request>
S: <expected-server-response>
with a few macros such as ${ignore} and ${rfcDate} to handle variable
protocol elements.

>
> I guess that tests which run on a clean build, with default configuration,
> would be the easiest start, otherwise we could end up bogged down in
issues
> of how to stop repository and mailet configuration errors obscuring bugs
in
> the servers & handlers?

Agreed, although developers are likely to have hacked the config file for
their own DNS settings anyway. What would be great is a way to use a
developer-specific properties file to automatically override certain
settings in the config file (or even better, an installer).

>
> I suggest we'd need three simple tests to start with
> 1/ create a test account

I've also got an "addUser" test, which uses the above framework against the
RemoteManager to add a named user.
(I expect to get this stuff committed within the next week or so).


> 2/ deliver to that account using SMTP
> 3/ collect the mail via POP

This would be great for a start. We probably want to test SMTP and POP on 2
levels.
1) Test the protocol for consistency, completeness and RFC compliance. This
could include issues such as handling different date formats,
case-sensitivity etc.
2) Full functional tests. Protocol-based testing probably isn't ideal for a
full set of functional tests; we might want to look at building tests on top
of JavaMail for this. (Or maybe there are some standard MailServer
functionality tests which would be just what we need?)

>
> the next logical one;
> 4/ deliver to a remote address
> is more problematic as it requires dns configuration, a good address to
> deliver to, and could still be caught out by the anti-spam mailets.

Agreed - but we'll probably all have a Test Account for this. Maybe the
actual address could be specified in a test config file (together with
settings like port numbers, timeouts etc.)

Good stuff to be thinking about, anyhoo.

ciao
Daz




--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message