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