James debugging

[Serge Knystautas <se...@lokitech.com>]

Debugging, well actually testing, is very difficult for mailets and 
matchers right now.  I remember we had talked about a development kit at 
one point, but I thought I'd offer a couple of suggestions.

- Have RemoteDelivery take a "debug" mode setting, and if on it would 
log what it would have done (deliver this message to these addresses), 
make no attempt to deliver it though, and then delete it.

- Create a collection of test messages (odd subjects, headers, 
attachments, whatever) that you can run against your matcher or mailet 
and check that there aren't unexpected exceptions.

- I'm not sure exactly how to get this working in a JUnit framework, but 
it would be nice to have a way to unit test mailets and matchers against 
a standard (and extendable) list of rfc822 messages.  So maybe we have 
10 or 15 standard messages that shouldn't make the mailet barf, and then 
let the user add additional messages.  Maybe also have the framework 
specify results for each of these messages, but that's a tougher test to 
setup.

I know Danny is working on mailet classloading which will make it much 
easier, but to the extent we could have some other facilities to debug 
mail applications, I think that'd be great.  Ideally these could run 
offline with ant, but also within James... so many developers now are 
used to changing a servlet or template and pulling up a webpage to test, 
but this is much more difficult to do with mail-based apps.

Just a late night tangent that hopefully might spark some ideas and 
interest.

-- 
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com/



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: James debugging

[Aaron Knauf <ak...@xtra.co.nz>]

I agree that this is a good idea.  Another (complimentary, rather than 
alternative,) approach could be to use mockobjects 
(http://www.mockobjects.com) to allow us to instantiate a mailet, pass 
in a mock MailetConfig to init, pass it either a mock Mail object, or 
one of your test messages, and let it rip.  JUnit asserts could then 
test to see what it did later.

The number of mockobjects required to test a non-trivial mailet might 
get pretty high, but many mailets are really pretty simple.

Just my $0.02.

ADK

Serge Knystautas wrote:

> Debugging, well actually testing, is very difficult for mailets and 
> matchers right now.  I remember we had talked about a development kit 
> at one point, but I thought I'd offer a couple of suggestions.
>
> - Have RemoteDelivery take a "debug" mode setting, and if on it would 
> log what it would have done (deliver this message to these addresses), 
> make no attempt to deliver it though, and then delete it.
>
> - Create a collection of test messages (odd subjects, headers, 
> attachments, whatever) that you can run against your matcher or mailet 
> and check that there aren't unexpected exceptions.
>
> - I'm not sure exactly how to get this working in a JUnit framework, 
> but it would be nice to have a way to unit test mailets and matchers 
> against a standard (and extendable) list of rfc822 messages.  So maybe 
> we have 10 or 15 standard messages that shouldn't make the mailet 
> barf, and then let the user add additional messages.  Maybe also have 
> the framework specify results for each of these messages, but that's a 
> tougher test to setup.
>
> I know Danny is working on mailet classloading which will make it much 
> easier, but to the extent we could have some other facilities to debug 
> mail applications, I think that'd be great.  Ideally these could run 
> offline with ant, but also within James... so many developers now are 
> used to changing a servlet or template and pulling up a webpage to 
> test, but this is much more difficult to do with mail-based apps.
>
> Just a late night tangent that hopefully might spark some ideas and 
> interest.
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>