parallel=methods & thread-safety

[Eric Jain]

When running with parallel="methods", does each thread get it's own
test class instances?

If not, it would seem that any test class with @BeforeMethod
initialization is unsafe to run in parallel (which is something TestNG
could warn about, come to think of it)?

[Stevo Slavić]

Hello Eric,

If I'm not mistaken, for each thread to have it's own instance of class being tested, to hold these instances you have to either use test method local variable or make use of ThreadLocal. When using ThreadLocal, to initialize instances being tested once per test thread, you have to override ThreadLocal's initialValue (in another recent topic I've asked for additional attribute for @BeforeClass to support running such annotated method per thread). With ThreadLocal you shouldn't have problems with @BeforeMethod.

Regards,
Stevo.

[Eric Jain]

On Sep 30, 11:51 am, "Stevo Slavić" <ssla...@gmail.com> wrote:
> Hello Eric,
>
> If I'm not mistaken, for each thread to have it's own instance of class
> being tested, to hold these instances you have to either use test method
> local variable or make use of ThreadLocal. When using ThreadLocal, to
> initialize instances being tested once per test thread, you have to override
> ThreadLocal's initialValue (in another recent topic I've asked for
> additional attribute for @BeforeClass to support running such annotated
> method per thread). With ThreadLocal you shouldn't have problems with
> @BeforeMethod.

Thanks, ThreadLocal could help, but that would also mean rewriting all
tests just so they can be run in parallel... Pity that TestNG isn't
smart enough to create one instance of a test class per thread when
running tests in parallel :-( Or would this have some undesirable side
effects?

[Cédric Beust ♔]

2008/9/30 Eric Jain <eric...@gmail.com>

Thanks, ThreadLocal could help, but that would also mean rewriting all
tests just so they can be run in parallel... Pity that TestNG isn't
smart enough to create one instance of a test class per thread when
running tests in parallel :-( Or would this have some undesirable side
effects?

It would be contrary to one of the TestNG design goals, which was that tests are not reinstantiated between method invocations.  I find it dangerous to have two different behaviors depending on whether the threads are being run in parallel or not...

--

Cédric

[Помазёнков Виталий]

Hi all!

If you use ThreadLocal, then be redy to get TestNG bug
http://jira.opensymphony.com/browse/TESTNG-265.
In short words, you can't use timeout parameter.

--
Виталий



Stevo Slavić пишет:

[Stevo Slavić]

Hello Vitalij,

@Test and its corresponding @BeforeMethod/@AfterMethod get called in same thread, and there seems to be no problem using ThreadLocal in either of them. Attached is a dummy class, it's test and a test suite you can try.

Regards,
Stevo.

[Помазёнков Виталий]

Try to use @Test(timeOut = 60000) annotation and you will see that
@BeforeMethod/@AfterMethod get called in different threads.

--
Виталий



Stevo Slavić пишет:

[Stevo Slavić]

Hello Vitalij,

You are right, there seems to be a bug when timeOut is specified. Attached is test eclipse maven project with test that was running well without timeOut set, but with timeOut set it breaks - test execution log shows that methods were called in wrong order, thread-wise:

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running TestSuite
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass beforeMethod
INFO: Thread[9] : beforeMethod
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass beforeMethod
INFO: Thread[8] : beforeMethod
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass testId2
INFO: Thread[10] : testId2
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass testId1
INFO: Thread[11] : testId1
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass afterMethod
INFO: Thread[8] : afterMethod
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass afterMethod
INFO: Thread[9] : afterMethod
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass beforeMethod
INFO: Thread[9] : beforeMethod
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass beforeMethod
INFO: Thread[8] : beforeMethod
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass testId2
INFO: Thread[12] : testId2
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass testId1
INFO: Thread[13] : testId1
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass afterMethod
INFO: Thread[9] : afterMethod
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass afterMethod
INFO: Thread[8] : afterMethod
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass beforeMethod
INFO: Thread[9] : beforeMethod
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass beforeMethod
INFO: Thread[8] : beforeMethod
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass testId2
INFO: Thread[14] : testId2
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass testId1
INFO: Thread[15] : testId1
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass afterMethod
INFO: Thread[9] : afterMethod
Oct 2, 2008 1:27:02 PM org.acme.test.foo.bar.TestDummyClass afterMethod
INFO: Thread[8] : afterMethod
Tests run: 6, Failures: 6, Errors: 0, Skipped: 0, Time elapsed: 0.391 sec <<< FAILURE!

Regards,
Stevo

[Помазёнков Виталий]

Yap :(
You can vote for my issue in TestNG Jira
http://jira.opensymphony.com/browse/TESTNG-265, but Cédric talls me that
it will be very difficult to fix it in TestNG, so I will use my own
timeout realisation.

--
Виталий



Stevo Slavić пишет:
> Hello Vitalij,
>

[Stevo Slavić]

Voted and attached test project. Hopefully it won't be that difficult to fix.

Regards,
Stevo.