[
https://issues.apache.org/jira/browse/OFBIZ-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858934#action_12858934
]
Bob Morley commented on OFBIZ-3670:
-----------------------------------
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?
> TestCase base classes providing ability to execute unit tests in Eclipse in
> "standalone" mode
> ---------------------------------------------------------------------------------------------
>
> Key: OFBIZ-3670
> URL: https://issues.apache.org/jira/browse/OFBIZ-3670
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
> Affects Versions: SVN trunk
> Reporter: Bob Morley
> Assignee: Scott Gray
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3670_StandaloneTestEnhancement.patch
>
>
> This patch provides the framework that allows junit unit tests to be executed
> directly in Eclipse (without having to invoke Start directly). It total it
> contains:
> - BaseTestCase - very top of the TestCase stack containing ofbiz specific
> assertions
> - StandaloneTestCase - determines if application has executed "Start"; if not
> it will execute a scaled down "Start unittest" that is used in Eclipse
> - RollbackTestCase - extends standalone and provides a transaction w/
> auto-rollback
> - TestRunContainer - provides ability to disable dispatcher attributes via
> configuration (used for unittest-containers.xml)
> - GeoWorkerTest - unittester that provides "full" coverage of GeoWorker; can
> be executed from Eclipse or from command-line as it is plugged into standard
> testdef framework. Creates its own entities with transaction start/rollback
> so it can be re-executed.
> Would appreciate if this can be a priority so I can provide additional test
> cases to boost our code coverage that will utilize these features.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
