Unexpected behavior in parallel execution of classes when testng contains packages

[Bhagyasri Srinivas]

Hi all,

I am facing problems with the following project setup.(Attaching the sample project code)

I have a web application with limited pool of credentials(4 to be specific) to login. I am making use of @BeforeTest where i am retrieving one of the credential object and releasing it in the @AfterTest. The entire suite runs in 4 threads in parallel as I have only 4 sets of credentials. What this also means that, I can not have more than one login session active at any point during the execution of the suite.I have around 5000 test cases and around 200+ test classes. All this used to work fine. 

Now my task is to run in to divide the tests in to modules and run them using testng groups. 

For this I created a testng file with below content in the Test tag and moved code that handles the credential retrieval to @BeforeClass and credential release to @AfterClass.

<test name="Test">

<groups>

<run>

<include name="gp1" />

</run>

</groups>

<packages>

<package name="com.local.automation" />

</packages>

</test>

With these changes, what i observed is that, the suite runs perfectly fine 

• when the test methods in any class are not dependent on any other test method 
• when the test methods in any class have no priorities assigned.

Where is the problem?

As per my observation, what is happening is the execution of @Beforeclass annotated method is happening as expected before the start of the execution of the test class.

 But in case of a test class having test methods which are either dependent on one other, or have some priorities assigned, after the execution of the first method in such class, the thread is kept on hold (with login session in to the application still open) and even though the configured thread count is 4, a new thread is being spanned which is trying to get user credentials from the pool. Since the pool does not have any un-allocated credentials, all the subsequent tests are failing.

Please let me know what is the default behavior of TestNG in this case ,and If it's indeed is a bug are there any work around's to make my use case work. 

NOTE: 

TestNG version: 6.14.3

Thanks,

Bhagyasri.

[Krishnan Mahadevan]

Bhagyasri,

 

Couple of things.

Latest released version of TestNG is 7.0.0.

 

How is the threadpool of your credentials being maintained? Can you show us some code snippets for that ? It looks like the user credentials threadpool is somehow being tied to the threads.

 

To the best of my knowledge, TestNG doesn’t work with a cachedthreadpool (which is where threads are re-used) but it works with a regular thread pool executor (which works with a LinkedBlockingQueue instead of using a SynchronousQueue and thus get the behavior of a cachedthreadpool).

 

Because of this, the behavior would be that the number of tasks remain controlled, but not the thread lifecycle.

 

You might want to revisit your logic wherein your logic doesn’t depend upon threads for your credentials pool.

 

Thanks & Regards

Krishnan Mahadevan

 

"All the desirable things in life are either illegal, expensive, fattening or in love with someone else!"

My Scribblings @ http://wakened-cognition.blogspot.com/

My Technical Scribbings @ http://rationaleemotions.com/

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to testng-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/testng-dev/93340f6b-9a13-49b6-8d8b-372a076e67e3%40googlegroups.com.