On 3/28/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > On 3/28/06, robert burrell donkin <[EMAIL PROTECTED]> wrote: > > On Mon, 2006-03-27 at 19:43 -0700, Phil Steitz wrote: > > > <snip/> > > > > * testPooling: This test method passes when you run it by itself. It > > > > fails because while it looks like it's written to handle either a FIFO > > > > or a LIFO pool implementation it doesn't if the GenericObjectPool > > > > backing Dbcp has more than 2 idle connections. When the test is run > > > > after other tests the GOP contains 4 idle connections. With a LIFO the > > > > most recently returned is the first one borrowed so it doesn't matter > > > > how many idle connections already exist at the start of the test. > > > > Since GOP is now a FIFO the test fails because is incorrectly assumes > > > > that a recently returned connection will be the next one borrowed. IMO > > > > testPooling should be removed as it really testing Pool's behavior and > > > > not Dbcp's behavior. > > > > > > Yes. This is bad and I agree this test case should be removed, as it > > > depends on the implementation of the underlying pool, which is not > > > part of [dbcp]. If there are no objections, I will remove this test > > > case. > > > > or replace with a mock pool implementation (if possible) > > This is an interesting idea. Would appreciate suggestions on how > exactly to do this.
I haven't dug into Dbcp code but I think the GenericObjectPool is deep within Dbcp as an internal data structure and I'd be surprised if it let you specify a specific pool implementation. Even if you do mock the pool, the test would be testing the behavior of the mock pool as called through Dbcp. I think any interesting interaction with the GOP would be implicitly tested by other unit tests. -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
