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:
Sent from the open-jpa-dev mailing list archive at

Reply via email to