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.
Also, there are some trivial "mock" Driver, Connection, ResultSet, etc. objects in the dbcp test tree. 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. (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.) On Fri, 24 Jan 2003, Steven Caswell wrote: > Sounds like option 4 could be written once and then configured for > different test cases. I suspect option 3 with a Mock object would > require more per-test effort. If this is the case, I'd definitely go for > option 4. And for driver-specific tests (i.e., OracleBugFixDriver), I'd > expect to have to write one-off tests for that anyway. > > Do you already have a TestDriver written? I can take a shot at an > initial cut if not. > > Have you put together a TestDriver scenario for the ResultSet wrapper? > If not, I can take a shot at that one also. > > Steven Caswell > [EMAIL PROTECTED] > a.k.a Mungo Knotwise of Michel Delving > "One ring to rule them all, one ring to find them..." > > > > -----Original Message----- > > From: Henri Yandell [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, January 23, 2003 11:04 PM > > To: Jakarta Commons Developers List; [EMAIL PROTECTED] > > Subject: Re: [dbutils] Test case approach > > > > > > > > This is where I am with dbutils at the moment. It needs a > > good system for creating a test-case that doesn't depend on > > someone providing a database, or having to lug a java-memory > > based db around. > > > > I can think of four options: > > > > 1) User must setup a db, with a user that can add tables. > > 2) We lug Axiom or HSQL or something around, and use that. > > 3) We look into the Mock object for a database. I'm not sure > > this will work, but need to learn more. > > 4) DbUtils contains an extension to the DriverWrapper's > > called TestDriver. This is given a Properties object which > > maps regular-expression SQL statements to a MemoryResultSet. > > > > Our test would build up an expected resultset, run the sql, > > then get that back. Or something. A fake database. > > > > It wouldn't be smart for insert/update/delete, so those > > statements would have to fire off modifications to the > > system. Complexity hits. > > > > This is your dummy-result set, but as a full-on driver > > extension. It wouldn't be able to test out: > > 'OracleBugFixDriver', but it would handle a lot of things. > > > > What do you think? > > > > Hen > > > > On Thu, 23 Jan 2003, Steven Caswell wrote: > > > > > I'd like to write a test case for the ResultSetWrapper and > > a couple of > > > subclasses I've written. I'm wondering about how to > > approach doing so. > > > Does it make more sense to write a stubbed-out ResultSet > > > implementation that just provides dummy returns, or is it > > necessary to > > > actually connect to a database and perform a real live honest to > > > goodness query? Since I really only care that the ResultSetWrapper > > > delegates method calls to the wrapper ResultSet, I don't > > see any need > > > of going through the effort of setting up a database > > connection, when > > > it seems that a dummy implementation would provide the same > > > capability. > > > > > > Opinions? > > > > > > > > > Steven Caswell > > > [EMAIL PROTECTED] > > > "In our own native land, in defense of the freedom that is our > > > birthright, and which we ever enjoyed till the late > > violation of it -- > > > for the protection of our property, acquired solely by the honest > > > industry of our fore-fathers and ourselves, against > > violence actually > > > offered, we have taken up arms. We shall lay them down when > > > hostilities shall cease on the part of the aggressors, and > > all danger > > > of their being renewed shall be removed, and not before." - Thomas > > > Jefferson > > > > > > > > > > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
