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 >
