I dug in a little bit further based on your direction and now I see what you are referring to wrt suspended transactions in a new service. Thought of a potential problem with the current approach and would like to run it by you – it appears that in all the code that does a DelegatorFactory.getDelegator will get the original delegator (not the "test" version) and consequently would not rollback. Perhaps I am missing where the test version of the delegator is stuffed into the delegator cache in DelegatorFactory ?
Reflecting on what the intent seems to be here, I would recommend that we consider a few minor changes.
1. We consider moving the test specific artifacts from GenericDelegator into either a TestGenericDelegator proxy or sub-class. I am kind of a big proponent of not having test specific code in production code; this proxy/sub-class could live in a org.ofbiz.entity.test package.
2. We consider a new implementation of DelegatorFactoryImpl which constructs "test" versions of the GenericDelegators. The very nice factory pattern would provide us with the ability to have this new test factory implementation and (hopefully) be able to easily plug it in when we run from the TestRunContainer or from a JUnit test case.
By doing number 2 what we would ensure is that all delegators created in a container that is for "test" would use test variants, would record their operations, and would "play them back" on rollback. My guess is that we may want to play a rollback on all delegators cached from a test run which would account for any multi-tenancy tests, etc.
I think we are now on the same page with this work and ensuring that the tests run in a consistent way. If you would like I could take a crack at these proposed changes for your review if you have not had time to start on your updates to my patch. Thoughts?