Menu
▾
▴
Re: [Springframework-developer] Testing Controllers and FormControllers
|
From: Thomas R. <tho...@tr...> - 2004-05-02 16:07:04
|
There is a SpringMockDataSource in the org.springframework.jdbc.support.SQLErrorCodesFactoryTests class. Don't think it is of any value for general use right now, but it was needed for the translation factory tests since every single instance of the easy mock datasource always returned the same hash value. Thomas jürgen höller [werk3AT] wrote: >I don't think that a separate mock module makes much sense: After all, the "test" tree of the framework itself depends on those mocks... It really should stay part of the main module. As you say, it's also easier in terms of release management. > >I don't think that the mocks will grow into something with its own release schedule: We're still recommending dynamic mocks a la EasyMock for most testing scenarios. Just when interfaces are really hard to mock dynamically because of inter-dependent and overlapping methods (attribute handling, parameters), we provide distinct mock objects: currently, just for the Servlet API and for JNDI. The only further candidate that I can think of at this point of time is the Portlet API. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von Alef Arendsen >Gesendet: So 02.05.2004 16:18 >An: spr...@li... >Betreff: RE: [Springframework-developer] Testing Controllers and FormControllers > > > > > >>I'd still prefer a separate tree. More for clarity when users >>browse code. A lot of people are likely to look at the source >>in the /src tree and be confused as to why there's test- >>related stuff there that isn't in spring.jar. >> >> >+1 > >It will result in all kinds of questions popping up on the lists. > >What about a separate module? Or did I miss the discussion there. It would >allow for separate development of the mock tree (and maybe other >test-related stuff). I imagine the amount of test-related supporting >features for 1.0.x to grow before 1.1 is released and people will be able to >use those enhancements as they are contained by separate releases (as >opposed to having them in the src or mock tree alongside the 1.0.x codebase >which might not be getting another release anymore). > >A separate module does however result in more complexity and work when doing >releases and stuff maybe... > >Alef > > >>Rgds, >>Rod >> >>---- Original message ---- >> >> >>>Date: Sun, 2 May 2004 13:26:29 +0200 >>>From: jürgen höller [werk3AT] <jue...@we...> >>>Subject: Re: [Springframework-developer] Testing Controllers >>> >>> >>and FormControllers >> >> >>>To: <spr...@li...> >>> >>>While I object to keeping our new mocks in the "test" tree, >>> >>> >>I'm not against keeping them in the "src" tree, excluding >>them from spring.jar and Clover coverage. Rod was quite keen >>on having the separate "mock" tree, so I guess we need to >>wait for his opinion, taking into account the Maven issue. >>Unfortunately, he won't be online before Tuesday morning... >> >> >>>In any case, it's important to agree on this before 1.0.2, >>> >>> >>which is currently scheduled for release in two weeks. >> >> >>>Juergen >>> >>> >>>________________________________ >>> >>>Von: spr...@li... >>> >>> >>im Auftrag von Luke Taylor >> >> >>>Gesendet: Fr 30.04.2004 21:44 >>>An: spr...@li... >>>Betreff: Re: [Springframework-developer] Testing Controllers >>> >>> >>and FormControllers >> >> >>> >>>My main concern isn't so much whether they are in the test >>> >>> >>or src tree, >> >> >>>it's just that the overall structure seems a bit haphazard. >>> >>> >>And I don't >> >> >>>see why they should be split from the core when other >>> >>> >>modules aren't. >> >> >>>If separate modules are going to be split from the codebase >>> >>> >>then it >> >> >>>would make sense to follow a standard pattern, e.g. >>> >>>core >>> | >>> - src >>> | >>> - test >>> >>>mock >>> | >>> - src >>> >>>other >>> | >>> - src >>> | >>> - test >>> >>>Ok, Ok... so my main concern is that it won't work with my >>> >>> >>Maven build >> >> >>>unless I hack it :) and until then my reports are stuck at >>> >>> >>Apr 28th. But >> >> >>>I agree with the aims Maven had of establishing a common >>> >>> >>structure for >> >> >>>project layouts, even though you could easily argue that >>> >>> >>they aren't >> >> >>>exactly a shining example of best practice development >>> >>> >>themselves. >> >> >>>Luke. >>> >>>jürgen höller [werk3AT] wrote: >>> >>> >>>>IMO, there's a strong difference between the "mock" and >>>> >>>> >>the "test" >> >> >>>>tree: The latter is a rough test suite for the framework >>>> >>>> >>itself, >> >> >>>>while the former contains polished mock classes that are >>>> >>>> >>also useful >> >> >>>>for applications, thus get distributed as "spring- >>>> >>>> >>mock.jar". The >> >> >>>>mocks would even fit better in "src" than in "test" in >>>> >>>> >>that respect. >> >> >>>>Actually, the "mock" tree is more similar to the >>>> >>>> >>main "src" tree than >> >> >>>>the "test" tree in a number of respects: It's meant to be >>>> >>>> >>used by >> >> >>>>applications, shipped as jar , included in the javadoc, >>>> >>>> >>and requires >> >> >>>>higher coding standards than the framework test suite. I'm >>>> >>>> >>quite >> >> >>>>strongly against keeping that sort of classes in >>>> >>>> >>the "test" tree. >> >> >>>>Juergen >>>> >>>> >>>> >>>> >>> >>>-- >>> Luke Taylor. Monkey Machine Ltd. >>> PGP Key ID: 0x57E9523C >>> >>> >>http://www.monkeymachine.ltd.uk >> >> >>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by: Oracle 10g >>>Get certified on the hottest thing ever to hit the market... >>> >>> >>Oracle 10g. >> >> >>>Take an Oracle 10g class now, and we'll give you the exam >>> >>> >>FREE. >> >> >>>http://ads.osdn.com/?ad_id149&alloc_id66&op=click >>>_______________________________________________ >>>Springframework-developer mailing list >>>Spr...@li... >>>https://lists.sourceforge.net/lists/listinfo/springframework- >>> >>> >>developer >> >> >>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by: Oracle 10g >>>Get certified on the hottest thing ever to hit the market... >>> >>> >>Oracle 10g. >> >> >>>Take an Oracle 10g class now, and we'll give you the exam >>> >>> >>FREE. >> >> >>>http://ads.osdn.com/?ad_id149&alloc_id66&opÀick >>>_______________________________________________ >>>Springframework-developer mailing list >>>Spr...@li... >>>https://lists.sourceforge.net/lists/listinfo/springframework- >>> >>> >>developer >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: Oracle 10g >>Get certified on the hottest thing ever to hit the market... Oracle 10g. >>Take an Oracle 10g class now, and we'll give you the exam FREE. >>http://ads.osdn.com/?ad_id149&alloc_id66&op=ick >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by: Oracle 10g >Get certified on the hottest thing ever to hit the market... Oracle 10g. >Take an Oracle 10g class now, and we'll give you the exam FREE. >http://ads.osdn.com/?ad_id149&alloc_id66&op=ick >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: Oracle 10g >Get certified on the hottest thing ever to hit the market... Oracle 10g. >Take an Oracle 10g class now, and we'll give you the exam FREE. >http://ads.osdn.com/?ad_id149&alloc_id66&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > |
