interesting and useful comments.
improved caching is something that i want to look at once this release is out of the way, so i think that probably the best thing to do would be to go without testing (of this fix) for this release.
if you'll hang around, maybe we can all try to work out some good strategies for cache testing and maybe open out this topic to other components which are likely to have similar needs (eg. collections, lang, reflection).
- robert
On Friday, October 18, 2002, at 11:33 PM, Steve Downey wrote:
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 +0100This is an area that I've often wondered about -- how do most people deal
From: robert burrell donkin <[EMAIL PROTECTED]>
Reply-To: Jakarta Commons Developers List
<[EMAIL PROTECTED]> To: Jakarta Commons Developers List
<[EMAIL PROTECTED]> 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).
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
CraigOn 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-> [EMAIL PROTECTED]> 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>
-- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
