can you explain how you make sure that each test starts from a clean DB ?

i also played with the idea that each test should delete its own generated data explicitely. but that turned out to be very impractical and tedious. usually when you forget to delete a record (and this can be very unexpected) it is not a problem so you won't know at that time. then when after a while a test might be created or changed and that might lead to a clash. those are typically very hard to find.

so far, clearing the whole db has proven to work well. but i'm open to hearing alternatives if you think they are better.

I made some tests for some more complex jBPM usage and had to adapt them to what Thomas did (great job). Just deleting each generated processDefinition seems to delete all related processInstances, logs etc... so it was as simple as putting a try/finally around my test and indeed keeping track of what processDefinitions I deployed.

If we adapt all tests to deploy via a deployProcessDefinitions method of the AbstractDBTestCase, it can keep track of all of them and automatically undeploy/delete at teardown. That would get rid of all try/catches again.

The only thing is that the System.exit stops the tests, but Eclipse thinks JUnit is still running... Initially (when I updated from SVN, I was confused.... The FIXME can have a little more explanation, but now I know this, it does not realy bother me

deleting deployed definitions and checking if no records are left seems more error prone to me then just deleting all records in the db.

but what you suggest works and that is the most important part. it's your call.

i don't think the same solution will hold in jbpm 4 as i'm not sure that we'll have the same behaviour for deletion of process definitions. i think it might be wise to have two separate methods: deleteAllExecutions and deleteProcessDefinition. Then deleteProcessDefinition could throw an exception if process executions are still around. but that decision is for later.