[
https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plug...
]
Tom Baeyens commented on JBPM-1280:
-----------------------------------
It's crucial that the job executor is tested on edge cases. Not only the normal
rollback and commits. But also 3 tests with a synchronizationsin the same
transaction:
* one that just does a transactional update to the db and succeeds
* one that throws an exception in the beforeCompletion (should cause a rollback of the
transaction)
* one that throws an exception in the afterCompletion (should cause the rest of the
transaction to commit)
Probably there are more of those specific situation that we need to cover.
I have started with the checking the basics in org.jbpm.pvm.api.db.tx.TransactionDbTest.
That test I just added to the CheckInTests. That test can give some inspiration on how to
find the edge cases for the job executor.
I have put the TransactionDbTest in the API part as I think it should run in any
environment.
build out job executor basic test coverage
------------------------------------------
Key: JBPM-1280
URL:
https://jira.jboss.org/jira/browse/JBPM-1280
Project: JBoss jBPM
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Assignee: Guillaume Porcher
Priority: Critical
Fix For: PVM 1.0 beta1
First, we need to establish what we're going to QA and how. I see 3 distinct types
of tests for the job executor
1) Using JobSession to create jobs and then use the JobExecutor API's to control the
execution of those jobs. This way, all these tests can and should be done in a single
thread.
* a commit for processing an asynchronous message
* a commit for processing a timer
* a commit for the combination of a an asynchronous message and a timer
* a commit with a custom resource in the standard transaction
* test a rollback caused by a user code exception in an asynchronous continuation
* test a rollback caused by a user code exception in an timer
* test a rollback caused by a user code exception with a custom resource in the standard
transaction
* test a rollback caused by an optimistic locking exception in an asynchronous
continuation
* test a rollback caused by an optimistic locking exception in an timer
* test a rollback caused by an optimistic locking with a custom resource in the standard
transaction
2) If we only use the public, stable API's, we'll be a lot more limited in what
we're able to test. We can e.g. run this test suite against the jBPM 3 codebase.
* create and execute a process with a couple of asynchronous continuation in it.
* create and execute a process with asynchronous continuations in a concurrent section.
* create and execute a process with a couple of timers in it.
* create and execute a process with a couple of timers in a concurrent section
* a combination of a timer and an asynchronous continuation
3) Load and stress tests. Also these should only make use of public API's and ways
to deploy processes. So that this test suite is configurable/runnable on different
environments (and also against the jBPM 3 codebase)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira