It is the next thing that even I was thinking off. I think this will add tremendous value to the existing product. We will be waiting for this version very soon. All the best to all the members who are involved in making this product sucessful.
Dhar ----- Original Message ----- From: "Vincent Massol" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, September 30, 2001 2:07 PM Subject: Re: make testing database code easier > Hi Greg, > > AFAIK, there are 2 schools for unit testing database access : > - use a real test database and set it up in a correct state before each > test. A solution is indeed to run a SQL script that creates tables (or > simply delete rows, ...), ... and supress it at the end > - use Mock Objects (see > http://www.mockobjects.com/papers/jdbc_testfirst.html for a tutorial testing > JDBC code). In which case, you don't need a database [you will need one for > you acceptance tests though but at least not for the unit tests] > > So far, Cactus has left the options open and you are free to choose whatever > solution you like. However, Cactus being also used for integration testing > and now including EJB testing, it is true that it would be nice if it could > help to test code that accesses the database. > > However, I would prefer not to touch at the core of Cactus and would prefer > to consider your suggestion as an extension. We have already had a proposal > for a Cactus extension (to help do load testing, see the todo list). My > current idea is : > > * to put any extension of XXXTestCase in org.apache.cactus.extensions. In > your case, that could be JdbcServletTestCase or JdbcEjbTestCase (when it > exists), or JdbcJspTestCase, or JdbcFilterTestCase. Writing these tests case > that extends the original Cactus test case is trivial. > > What do you put exactly in the .dbSetUp and .dbTearDown ? SQL commands ? Who > executes these command ? The new JdbcServletTestCase ? On the client side or > the server side ? Where do you configure JDBC access; using a DataSource > [then it would need to be executed on the server side, probably] ? > > In Summary, I like your idea and I think it would make an interesting > extension. Please go ahead and submit it ! > > What do others think ? > Thanks > -Vincent > > > ----- Original Message ----- > From: "Greg Lappen" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, September 30, 2001 5:37 AM > Subject: Idea: make testing database code easier > > > > While trying to figure out how to integrate unit tests > > into our project, I kept getting hung up on the need > > for the database to be in a known state. I've tried > > writing tests before that insert data in the setUp() > > method and delete it in the tearDown(), but this can > > get tedious fast. > > > > My solution: > > > > Have two files for every TestCase class: > > > > <TestClassName>.dbSetUp > > <TestClassName>.dbTearDown > > > > These files will contain SQL commands, one per line. > > The commands in each file will be executed > > automatically (if they exist in the classpath) during > > setUp() and tearDown() respectively. > > > > My question: what's a good place in the cactus > > framework to put such functionality? Could > > ServletTestCase call this functionality at the > > appropriate times in the test execution? > > > > Comments? I almost have a prototype working and will > > submit some code when I get a chance. > > > > Thanks, > > > > Greg > > > > __________________________________________________ > > Do You Yahoo!? > > Listen to your Yahoo! Mail messages from any phone. > > http://phone.yahoo.com > >
