8 messages in org.apache.commons.devRe: Dbcp unit test failures with Pool...| From | Sent On | Attachments |
|---|---|---|
| Sandy McArthur | Mar 26, 2006 11:14 pm | |
| Phil Steitz | Mar 27, 2006 6:42 pm | |
| robert burrell donkin | Mar 28, 2006 1:25 pm | |
| Phil Steitz | Mar 28, 2006 6:32 pm | |
| Sandy McArthur | Mar 28, 2006 6:59 pm | |
| Peter Steijn | Mar 28, 2006 8:23 pm | |
| Craig McClanahan | Mar 28, 2006 8:29 pm | |
| Sandy McArthur | Mar 28, 2006 8:51 pm |
| Subject: | Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4] | |
|---|---|---|
| From: | Sandy McArthur (sand...@apache.org) | |
| Date: | Mar 28, 2006 6:59:28 pm | |
| List: | org.apache.commons.dev | |
On 3/28/06, Phil Steitz <phil...@gmail.com> wrote:
On 3/28/06, robert burrell donkin <robe...@blueyonder.co.uk> 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