6 Replies Latest reply on Feb 27, 2009 2:07 PM by alrubinger

TCK testcases for JCA spec 10 chapter - WorkManager

jeff.zhang Feb 20, 2009 2:07 AM

1. WorkManager.doWork
2. WorkManager.startWork
3. WorkManager.scheduleWork
Create some Work implement and run the test

4. Test for WorkListener/WorkAdapter/WorkEvent , verify it can be reached some status: workSubmit, workStarted, workAccepted, workRejected, workCompleted. Include catch some exception

5. Test ExecutionContext class, how?

6. Using Timer to periodic execution of work instance.

7. DistributableWork, do testcase as Work

1. Re: TCK testcases for JCA spec 10 chapter - WorkManager

jesper.pedersen Feb 23, 2009 12:07 PM (in response to jeff.zhang)
The specification released test cases for Chapter 10 are both the actually API but more importantly the actual specification text.

F.ex. if you look at the 2nd paragraph in 10.1 - you'll see

Even though a resource adapter may create Java threads directly and use them to do its work, an application server may prevent it from creating threads for efficiency, security, and manageability reasons. In such situations, a resource adapter needs a mechanism to obtain threads from an application server to do its work.

so we should have test cases where the resource adapter uses the WorkManager's thread pool and where it creates its own threads.

At some point we will have a switch where we will disallow the resource adapters to create their own threads.

If you look at the first bullet on page 230 (10.1 paragraph 4) it says that

An application server is optimally designed to manage system resources such as threads. It may pool threads and reuse them efficiently across different resource adapters deployed in its runtime environment.

so that means that we

1) Should have a ThreadPool for the WorkManager
2) Delegate the Work instances to the ThreadPool for execution

(We have a simple test for 1) currently in the test suite)

For 2) we must test that Work has executed in a separate thread.

So for the specification test cases you must go through each paragraph in the chapter and see if there are any test cases for that paragraph. Of course there must be both positive and negative test cases - like we talked about before.

The test cases must identify which chapter / section / paragraph they relate to - f.ex.

package org.jboss.jca.test.core.spec.chapter10.section1; ... /** * Test for paragraph 4 : bullet 1 */ @Test public void testWorkManagerHasThreadPool()

Here is another example from 10.3 paragraph 4:

However, the application server must use threads of the same thread priority level to process Work instances submitted by a specific resource adapter.

So the test case must check that the priority of all the threads in the thread pool have the same value.

So think about how you would write the TCK test suite for the entire specification - as we need full coverage.

Hope this helps !
Actions
2. Re: TCK testcases for JCA spec 10 chapter - WorkManager

jeff.zhang Feb 25, 2009 3:45 AM (in response to jeff.zhang)

Yeah, it is very helpful, Thanks ;)

here are 2 questions:
1. We need test RA behavior also? Like in the first bullet on page 230 (10.1 paragraph 4) it says that:
reuse them efficiently across different resource adapters deployed in its runtime environment

We can test this by adding 2 fake RAs.

2. Some description is "maybe" like
An application server may disallow resource adapters from creating their own threads based on its security policy setting, enforced by a security manager.

We will support this feature by disallowing creating thread in the RA, or we give a property that user can configure it?
Actions
3. Re: TCK testcases for JCA spec 10 chapter - WorkManager

jesper.pedersen Feb 25, 2009 9:44 AM (in response to jeff.zhang)

1. We need test RA behavior also? Like in the first bullet on page 230 (10.1 paragraph 4) it says that:

Yes, you could do it that way - having each RA submit more Work instances than there are threads in the pool and having them all complete their Work. You need to fill up the thread pool entirely before Work start to complete to test the blocking behavior.

Of course we need to count on the thread pool implementation - as we shouldn't test its implementation in this project - only its usage.

2. Some description is "maybe" like

These should be noted in the test suite, but left empty for now. However an issue (Task / Minor) should be filed with the implementation such that we keep track of them (including chapter / section / paragraph). As you said we may have flags for these at some point.

HTH
Actions
4. Re: TCK testcases for JCA spec 10 chapter - WorkManager

jeff.zhang Feb 27, 2009 1:09 AM (in response to jeff.zhang)

Do you think we can use mock object (like EasyMock) to test these cases?
Actions
5. Re: TCK testcases for JCA spec 10 chapter - WorkManager

jesper.pedersen Feb 27, 2009 1:05 PM (in response to jeff.zhang)

I don't see a problem of using EasyMock 2.4+ in our test suite, so feel free to include it.

I know that you can pull it from a Maven repository like our other dependencies.
Actions
6. Re: TCK testcases for JCA spec 10 chapter - WorkManager

alrubinger Feb 27, 2009 2:07 PM (in response to jeff.zhang)

Hey Jeff:

So I see you're using the EmbeddedTestMcBootstrap[1] for the tests. Thought I'd offer some notes:

This class is a hacky, simplified view of MC for use in testing only. Very simply, its job is to:

* Start up an MC Kernel
* Start up the virtual deployment framework
* Allow you to deploy MC XML into it (Like the *-jboss-beans.xml format used in AS)
* Do installs/lookups into MC

Objects that you install via the bootstrap really get installed into MC, and also take advantage of the MC lifecycle callbacks.

Any futher questions on its usage, reply here and I'll see what I can do to answer them.

S,
ALR

[1] http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/test/src/main/java/org/jboss/ejb3/test/mc/bootstrap/EmbeddedTestMcBootstrap.java
Actions

Go to original post