commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject RE: [dbutils] Test case approach
Date Fri, 24 Jan 2003 16:13:27 GMT


On Fri, 24 Jan 2003, Rodney Waldhoff wrote:

> For what it's worth, commons-dbcp has pieces of this.
>
> Initially, the org.apache.commons.dbcp.DelegatingXXX classes were just
> that--all they did was implement the XXX interface, take an XXX instance
> in the constructor and delegate all calls to that instance.  Later,
> additional functionality was added to the DelegatingXXX level (that
> probably should have been pushed down to one of the specific subclasses).
> I'd actually like to split that back out (and perhaps factor out a generic
> jdbc-delegates component/jar entirely). It's a useful way to hack aspects
> in (collect stats or performance numbers on jdbc activity, add logging of
> jdbc activity, etc), besides being useful for more specific apps like
> dbcp.

Is it exactly like org.apache.commons.dbutils.driver.*? [or something with
more bugfixes in?]. Any interest in refactoring dbcp and extracting? I
assume dbcp doesn't want to add the scope of dbutils to itself.

> Also, there are some trivial "mock" Driver, Connection, ResultSet, etc.
> objects in the dbcp test tree.

Sound good :)

> Is this the goal of dbutils?  If so, sign me up as a client if not a
> contributor.  Teasing apart (again) the pure delegates from implementation
> specific stuff in dbcp has been on my to-do list for while.

Common independent jdbc functions. One section being a set of wrapping
drivers.

Currently I'm just dumping useful things in prior to an argument when
dbutils has enough interest as to where code should go project wise.

For example, I've got a DbPoller in my sandbox atm to commit and am
working on a PropertiesJndi implementation which although it's targetted
for DB usage, isalready non-db enough to not be committed.


> (Personally I've been using axion in lieu of mock-database objects of any
> sort, with a great deal of success, but maybe I'm biased.  I think Hen's
> #2 works really well.)

For unit testing an actual application it seems good, but to unit test
DbUtils.closeQuietly(Connection) Axiom seems a bit heavy :) I guess we
could just go that approach though.

Any ideas on nice ways to setup Axiom as a part of the ant/maven build
structure?

Hen


--
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