RE: [Springframework-developer] Testing JavaMail

[Trevor C. <pr...@se...>]

There is an article on creating a simple smtp server for unit testing at
http://www.javaworld.com/javaworld/jw-08-2003/jw-0829-smtp.html .  It might
be more work than it's worth, but it would avoid making the tests
optional/seperate download.

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: September 28, 2003 3:36 PM
To: al...@jt...
Cc: spr...@li...
Subject: Re: [Springframework-developer] Testing JavaMail


Unfortunately we couldn't bundle it up (or any other GPL library) with
Spring, or Spring itself would have to become GPL. With GPL code (as
opposed to LGPL), this applies even if trying to use reflection to not
do direct imports of library classes; just the act of bundling the stuff
together is viral, to the best of my knowledge. However, one option
would be to provide information on where it could be pulled down, and
have that part of the testsuite become conditional.

This strategy would work with any library which is GPL and which doesn't
actually have to be referred to by Java code (ie there is no need for
imports).

It's obviously easier and cleaner to use a non-GPL alternative, if one
can be found. One other possiblity is to approach the dumbster author an
ask if he is ammenable to switching licenses from GPL to LGPL. I have
had some success with this strategy in the past.

Regards,
Colin


Alef Arendsen (JTeam) wrote:

>I've taken a look at the JavaMail package and it's tested right now.
>However, I could not find the mailer we used internally anymore, so I've
>snatched another mockup mailserver form the net. However, the library is
>licensed under GPL. I've never really understood how to handle GPL
>licenses when you're just using the library for testing purposes and
>stuff... Any objections?
>
>Furthermore, I was wondering why not all of the properties JavaMail
>specified can be set in the MailSetings object. For instance
>mail.smtp.port cannot be set?
>
>Any comments?
>
>Alef
>
>P.s. the mail library is located at
>http://sourceforge.net/projects/dumbster
>
>-----Oorspronkelijk bericht-----
>Van: spr...@li...
>[mailto:spr...@li...] Namens
>Rod Johnson
>Verzonden: Tuesday, September 23, 2003 8:50 AM
>Aan: al...@jt...; spr...@li...
>Onderwerp: Re: [Springframework-developer] Test coverage
>
>
>I took a look and mocking JavaMail isn't really an option (superbly
>untestable API, with static methods and final classes).
>
>So this is probably the only way to go... Thanks.
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "Alef Arendsen (JTeam)" <al...@jt...>
>To: "'Rod Johnson'" <rod...@in...>;
><spr...@li...>
>Sent: Monday, September 22, 2003 10:48 PM
>Subject: RE: [Springframework-developer] Test coverage
>
>
>
>
>>If nobody's busy doing it already, I'll see what I can do on the
>>javamail package. I've got a devnull mailer lying around somewhere
>>that we use for testing, maybe I can integrate it somehow...
>>
>>By the way, up to 76,7 now...
>>
>>Alef
>>
>>-----Oorspronkelijk bericht-----
>>Van: spr...@li...
>>[mailto:spr...@li...] Namens
>>Rod Johnson
>>Verzonden: Saturday, September 20, 2003 11:17 PM
>>Aan: spr...@li...
>>Onderwerp: [Springframework-developer] Test coverage
>>
>>
>>I think one of the things that has contributed to the success and
>>quality of Spring is our commitment to a good test suite. I've put a
>>fair bit more work into the test suite over the weekend, with the
>>upgrade to EasyMock 1.0 and new test suites for Velocity etc.
>>
>>I'm really pleased that everyone is emphasising tests in new coding,
>>but there is a still a bit of catchup to do.
>>
>>With this and Alef's new tag tests, test coverage is now 75.8%. I'd
>>like to see this go above 80% before 1.0RC1.
>>
>>So I think we should all kick in and add tests to our areas of
>>interest. Please run the Clover analysis as a starting point.
>>
>>Current major gaps include:
>>- XSLT support. I wrote this code so I guess I really should do the
>>tests but I'm not sure I have time. (These days I work entirely test
>>first, but I wrote that last year.) If any of the dev team are using
>>this, maybe they could take a look? It might require some refactoring.
>>- jdbc.core.support: No tests for incrementer support. Can the
>>developers looking after this please try to add some tests?
>>
>>Any volunteers for these or other areas in which tests can be
>>improved?
>>
>>Regards,
>>Rod
>>
>>
>>





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer