commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <steve.dow...@netfolio.com>
Subject Re: [beanutils] ready for 1.5 release?
Date Fri, 18 Oct 2002 22:33:16 GMT
If an API can't be tested, I tend to think there is something wrong with it. 
I've occasionally resorted to using protected deprecated methods to create a 
'Testable' version of a class. Our practice is to have the tests in a 
different package than the classes being tested, so package scope doesn't 
help.

Another tack, for aspects like cacheing, which really need to be invisible, is 
to add instrumentation. Either some way of quering cache stats, or 
registering a callback or event handler for cache misses. 

In practice, I like to be able to monitor the performance of a cache. The 
cache strategy might need to be changed, or the cache dumped entirely, if the 
cache just adds overhead. The application shouldn't care about caching, but 
the management of the app might.



On Friday 18 October 2002 03:01 pm, Craig R. McClanahan wrote:
> On Fri, 18 Oct 2002, robert burrell donkin wrote:
> > Date: Fri, 18 Oct 2002 19:47:07 +0100
> > From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
> > Reply-To: Jakarta Commons Developers List
> > <commons-dev@jakarta.apache.org> To: Jakarta Commons Developers List
> > <commons-dev@jakarta.apache.org> Subject: Re: [beanutils] ready for 1.5
> > release?
> >
> > the patch looks ok.
> >
> > since it's a fix for a caching bug and all the caching code is private to
> > the class, it's going to be very hard to create a test case without
> > changing some of the variables from private to package (say).
>
> This is an area that I've often wondered about -- how do most people deal
> with writing unit tests for this sort of stuff?
>
> In principle, I think it'd be OK to make things package instead of
> private, if we also seal the JAR file (i.e. add a "Sealed:" attribute in
> the manifest) to prevent application classes from declaring themselves
> into the org.apache.commons.beanutils package and therefore gaining access
> to these variables.
>
> > it shouldn't be too hard to create a test case but the question is
> > whether it's worth altering the API to do so. if the general feeling is
> > that a test case for this issue is worth making this change, i'll take a
> > look at writing one now.
> >
> > - robert
>
> Craig
>
> > On Friday, October 18, 2002, at 07:29 PM, Scott Sanders wrote:
> > > With the exception of 12728/12458.
> > >
> > > I have not yet looked at creating a test case for it, but I do believe
> > > the patch is solid.
> > >
> > > I have attached it if you get a chance to look at it.
> > >
> > > Other than that, I think we are ready.
> > >
> > > Scott
> > >
> > >> -----Original Message-----
> > >> From: robert burrell donkin
> > >> [mailto:robertburrelldonkin@blueyonder.co.uk]
> > >> Sent: Friday, October 18, 2002 11:24 AM
> > >> To: Jakarta Commons Developers List
> > >> Subject: [beanutils] ready for 1.5 release?
> > >>
> > >>
> > >> are we ready for a beanutils 1.5 release?
> > >>
> > >> - robert
> > >>
> > >>
> > >> --
> > >> To unsubscribe, e-mail:
> > >> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > >> For
> > >> additional commands,
> > >> e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> > >
> > >  --
> > > To unsubscribe, e-mail:  
> > > <mailto:commons-dev-unsubscribe@jakarta.apache. org>
> > > For additional commands, e-mail:
> > > <mailto:commons-dev-help@jakarta.apache. org>
> >
> > --
> > To unsubscribe, e-mail:  
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org> For additional
> > commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


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


Mime
View raw message