Menu
▾
▴
springframework-developer
|
From: Rod J. <rod...@in...> - 2003-05-11 17:40:35
|
Guys, As you know I'm pretty big on test coverage and (ideally) test-first development. I've added a few more tests over the weekend, and I've just achieved a significant boost in coverage by writing an introspection-driven test suite that achieves 100% coverage of Tony's 2000 line ObjectArrayUtils, in little more than 100 lines of test case. I guess it goes to show that where there's a will there's a way, where testing is concerned. (There weren't any bugs in it, by the way.) This raises overall test coverage from just on 50% (after my other test additions), to 56%. Regards, Rod |
|
From: Rod J. <rod...@in...> - 2003-05-11 17:53:23
|
I should add that Juergen's been doing sterling work adding tests and writing test-first lately, so we're up from 42% to 56% in a couple of weeks! R |
|
From: Rod J. <rod...@in...> - 2003-09-20 21:17:15
|
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 |
|
From: Darren D. <da...@da...> - 2003-09-21 00:54:38
|
On Saturday 20 September 2003 22:16, Rod Johnson wrote: > 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. I may be able to help out a little on this next week. Although I've switched mostly to Velocity, I was using XSLT support a lot recently. -- Darren Davison Public Key: http://www.davison.uk.net/key.jsp |
|
From: Darren D. <da...@da...> - 2003-09-24 00:14:47
Attachments:
FormatHelper.patch
FormatHelperTests.patch
|
On Sunday 21 September 2003 01:54, Darren Davison wrote: > On Saturday 20 September 2003 22:16, Rod Johnson wrote: > > 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. > > I may be able to help out a little on this next week. Although I've > switched mostly to Velocity, I was using XSLT support a lot recently. suggested patches for FormatHelper and corresponding FormatHelperTests attached.. still hoping to look at XSLT view this week. hth, -- Darren Davison Public Key: http://www.davison.uk.net/key.jsp |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-09-22 21:36:51
|
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 |
|
From: Rod J. <rod...@in...> - 2003-09-23 06:50:12
|
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 > > |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-09-28 12:53:09
|
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 > > ------------------------------------------------------- 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 |
|
From: Colin S. <col...@ex...> - 2003-09-28 20:33:24
|
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 >> >> >> |
|
From: Trevor C. <pr...@se...> - 2003-09-28 21:00:15
|
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 |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-09-29 01:51:39
|
This is exactly where I got the simple server from! It's quite good actually. We creating something similar at my company, but it got lost in the trash and I don't have the time to redo it ;-)... I'll contact the guy who wrote it to see what the options are... Alef -----Oorspronkelijk bericht----- Van: Trevor Cook [mailto:pr...@se...] Verzonden: Sunday, September 28, 2003 11:00 PM Aan: al...@jt... CC: spr...@li... Onderwerp: RE: [Springframework-developer] Testing JavaMail 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 |
|
From: Rod J. <rod...@in...> - 2003-12-09 17:25:53
|
To all developers: Can we please make an effort to raise test coverage as a priority from now on. We're at 76.8% with warn logging (close to 79 I think with debug logging). Please all run the clover target . The weakest packages are: - jdbc.support.incrementer (0) - jdbc.support.log (0) - nativejdbc (0) - mail.cos (0) - ibatis.support (0) - web.multipart(0) - view.document (0) The coverage report is also quite informative about what code is not being exercised. I think we should think about what of that code is no longer required; now is our last opportunity to get rid of unused features. I think the coverage on the core is excellent, but I would feel happier if we could get beyond 80% overall. If anyone else would like to contribute tests, that's most welcome too! Regards, Rod |
