The way I usually do things is by starting a transaction, and simply rolling it back when my test finishes (if it wasn't committed/rolled back during the test method). This usually supports 90% of an application integration tests needs. In my case, I have simple tests, I am running them against an in memory HSQL, and the costs are very small. I need this feature since I also test the transaction integration, and it requires more complex scenario then the test scenario I described in the beginning. I don't want to "corrupt" my code with Jdbc code that could be avoided.
As developers of tools/libraries/frameworks, we need to give the developers all the options, and educate them regarding the benefits/drawbacks of using each one. I am glad for the response in this thread! I have been burned by other libraries that are pretty nasty in their responses (but I won't name names :) ). robert burrell donkin-2 wrote: > > On 1/2/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: >> >> Personally, I like to put both the data cleanup and data >> initialization in the setUp() stage. It's sometimes a bit slower, but >> if there is faulty cleanup logic in a previous test's tearDown(), it >> may affect some random test down the road, and it can sometimes be >> very difficult to track down. > > i found that data cleaning in both setUp() and tearDown(), is > necessary (at least for standard commercial development) > > - robert > > -- View this message in context: http://www.nabble.com/Perform-automatic-drop-and-create-db-schema-tf2909915.html#a8131565 Sent from the open-jpa-dev mailing list archive at Nabble.com.
