[jbpm-issues] [JBoss JIRA] Commented: (JBPM-1280) build out job executor basic test coverage

[Tom Baeyens (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBPM-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12425408#action_12425408 ] 

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