Threads and instance per method & Spring

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Threads and instance per method & Spring

tarun3kumar

Hi,

TestNG does not create an instance of the test class for every testMethod. Is there a way to tell TestNG to create an instance for every testMethod?

This is useful when using spring's integration test like AbstractTransactionalDataSourceSpringContextTests which has the option to autowire dependencies. So if an instance for every method is not created stale prototype beans injected by Spring will get polluted if any test method modifies it, another test uses the same bean. You could argue that creating a setUp methods and manually looking up dependencies will alleviate the problem, but, this defeats the purpose of having Spring and being able to easily inject your dependencies and thus improve productivity.

When you specify to run methods in a test class in multiple threads does each thread create an instance of the test class for each of the test methods?

Thanks
Monal
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=58311&messageID=114690#114690


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Threads and instance per method & Spring

Hani Suleiman

Oh interesting, I think I can fix this inside of the  
org.testng.spring.test classes so that injection happens before every  
test. I'll have a look and see what's possible.

On Jan 12, 2007, at 2:53 PM, Monal wrote:

>
> Hi,
>
> TestNG does not create an instance of the test class for every  
> testMethod. Is there a way to tell TestNG to create an instance for  
> every testMethod?
>
> This is useful when using spring's integration test like  
> AbstractTransactionalDataSourceSpringContextTests which has the  
> option to autowire dependencies. So if an instance for every method  
> is not created stale prototype beans injected by Spring will get  
> polluted if any test method modifies it, another test uses the same  
> bean. You could argue that creating a setUp methods and manually  
> looking up dependencies will alleviate the problem, but, this  
> defeats the purpose of having Spring and being able to easily  
> inject your dependencies and thus improve productivity.
>
> When you specify to run methods in a test class in multiple threads  
> does each thread create an instance of the test class for each of  
> the test methods?
>
> Thanks
> Monal
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?
> threadID=58311&messageID=114690#114690
>
>
> >


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Threads and instance per method & Spring

Cédric Beust ♔
In reply to this post by tarun3kumar
Hi, Monal,

On 1/12/07, Monal <[hidden email]> wrote:

Hi,

TestNG does not create an instance of the test class for every testMethod. Is there a way to tell TestNG to create an instance for every testMethod?

This is useful when using spring's integration test like AbstractTransactionalDataSourceSpringContextTests which has the option to autowire dependencies. So if an instance for every method is not created stale prototype beans injected by Spring will get polluted if any test method modifies it, another test uses the same bean. You could argue that creating a setUp methods and manually looking up dependencies will alleviate the problem, but, this defeats the purpose of having Spring and being able to easily inject your dependencies and thus improve productivity.

Interesting.  I'll let Hani do some exploration and see if he can fix this at the Spring-TestNG level, because I'd rather avoid introducing this in TestNG if possible.  But I acknowledge it's a valid scenario.
 

When you specify to run methods in a test class in multiple threads does each thread create an instance of the test class for each of the test methods?

No, the instances are shared, just like in the non-multithreaded case.

--
Cédric
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Threads and instance per method & Spring

tarun3kumar
In reply to this post by Hani Suleiman

Hi Hani & Cedric,

Temporarily I have solved the issue in the following way:

All my integration tests extend the following class:
                         
public class MyAbstractTransactionalSpringIntegrationTests extends AbstractTransactionalDataSourceSpringContextTests {

       // The following two methods are for converting this into a TestNG class
        @BeforeMethod
        protected final void nGSetup() throws Exception {
                super.setUp();
        }

        @AfterMethod
        protected final void nGTearDown() throws Exception {
                super.tearDown();
        }
          ...
          ...
          ...
}

The above two methods and the annotations ensure that spring injects the dependencies before every test method is run in subclasses. This is not an ideal solution but was the only quickest way I could think of for making the existing Spring stuff work with a TestNG test class.

I am currently extending Spring's JUnit Integration test. Although, I would love to use Hani's stuff. Hani, what would you recommend I wait for a bit or is the TestNG-Spring stuff ready.

Thank you
Monal
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=58311&messageID=114834#114834


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Threads and instance per method & Spring

Hani Suleiman

hmm! That's exactly what the tng-spring classes do!

Can you try it from sources? Go into the testng spring directory, run  
ant, and that should spit out a jar file for you. Extend  
org.testng.spring.test.  
AbstractTransactionalDataSourceSpringContextTests and it should all  
work.

On Jan 12, 2007, at 5:02 PM, Monal wrote:

>
> Hi Hani & Cedric,
>
> Temporarily I have solved the issue in the following way:
>
> All my integration tests extend the following class:
>
> public class MyAbstractTransactionalSpringIntegrationTests extends  
> AbstractTransactionalDataSourceSpringContextTests {
>
>        // The following two methods are for converting this into a  
> TestNG class
> @BeforeMethod
> protected final void nGSetup() throws Exception {
> super.setUp();
> }
>
> @AfterMethod
> protected final void nGTearDown() throws Exception {
> super.tearDown();
> }
>           ...
>           ...
>           ...
> }
>
> The above two methods and the annotations ensure that spring  
> injects the dependencies before every test method is run in  
> subclasses. This is not an ideal solution but was the only quickest  
> way I could think of for making the existing Spring stuff work with  
> a TestNG test class.
>
> I am currently extending Spring's JUnit Integration test. Although,  
> I would love to use Hani's stuff. Hani, what would you recommend I  
> wait for a bit or is the TestNG-Spring stuff ready.
>
> Thank you
> Monal
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?
> threadID=58311&messageID=114834#114834
>
>
> >


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Threads and instance per method & Spring

tarun3kumar

Hani,

So if I understand correctly the testng-spring stuff tries to retrofit Spring's AbstractTransactionalDataSourceSpringContextTests (which extends Junit TestCase) to work with TestNG. However, testng-spring classes are not a rewrite to be independent of Junit's TestCase?

I will give the testng-spring classes a try.

Just a thought:
Just retrofiting may not be that big of an issue, but having the inherited assert** methods from JUnit's TestCase and the onese from org.testng.Assert class may get you into trouble. There may be additional such small nitpicks with retrofitting.

I briefly looked into rewriting the Spring's integration tests stuff to be free of Junit, but looking at what Spring has in their Sandbox for JPA and thinking about maintaining these to be in sync with Spring's changes deterred me from looking any further.

Thank you
Monal
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=58311&messageID=114839#114839


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Threads and instance per method & Spring

Hani Suleiman

Basically what we have is a copy of their classes, except without the  
TestCase superclass at the root of the heirarchy, and with the  
appropriate @Before/AfterMethod annotations on setUp and tearDown.  
That's pretty much the only change.

I haven't ported the JPA stuff yet since I'm not entirely sure on  
what the semantics of runBare are in JUnit, which the  
AbstractJpaTests rely on.

On Jan 12, 2007, at 5:40 PM, Monal wrote:

>
> Hani,
>
> So if I understand correctly the testng-spring stuff tries to  
> retrofit Spring's AbstractTransactionalDataSourceSpringContextTests  
> (which extends Junit TestCase) to work with TestNG. However, testng-
> spring classes are not a rewrite to be independent of Junit's  
> TestCase?
>
> I will give the testng-spring classes a try.
>
> Just a thought:
> Just retrofiting may not be that big of an issue, but having the  
> inherited assert** methods from JUnit's TestCase and the onese from  
> org.testng.Assert class may get you into trouble. There may be  
> additional such small nitpicks with retrofitting.
>
> I briefly looked into rewriting the Spring's integration tests  
> stuff to be free of Junit, but looking at what Spring has in their  
> Sandbox for JPA and thinking about maintaining these to be in sync  
> with Spring's changes deterred me from looking any further.
>
> Thank you
> Monal
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?
> threadID=58311&messageID=114839#114839
>
>
> >


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Threads and instance per method & Spring

Hani Suleiman
In reply to this post by tarun3kumar

I've played with this a bit, and I thikn I'm missing something from  
your usecase.

in JUnit, for every test method, the beans from the context are  
injected. The beans themselves are not reloaded or re-initialized,  
due to the context caching that the base class does. So if you change  
an injected dependency, it will remain modified in the next test  
invocation. If you want everything to be reinitialised, you'd have to  
call setDirty to force reloading of the context. The testng classes  
work the exact same way, unless I'm missing something?

On Jan 12, 2007, at 2:53 PM, Monal wrote:

>
> Hi,
>
> TestNG does not create an instance of the test class for every  
> testMethod. Is there a way to tell TestNG to create an instance for  
> every testMethod?
>
> This is useful when using spring's integration test like  
> AbstractTransactionalDataSourceSpringContextTests which has the  
> option to autowire dependencies. So if an instance for every method  
> is not created stale prototype beans injected by Spring will get  
> polluted if any test method modifies it, another test uses the same  
> bean. You could argue that creating a setUp methods and manually  
> looking up dependencies will alleviate the problem, but, this  
> defeats the purpose of having Spring and being able to easily  
> inject your dependencies and thus improve productivity.
>
> When you specify to run methods in a test class in multiple threads  
> does each thread create an instance of the test class for each of  
> the test methods?
>
> Thanks
> Monal
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?
> threadID=58311&messageID=114690#114690
>
>
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Threads and instance per method & Spring

tarun3kumar

You are right Hani, the context is cached unless explicitly cleared via setDirty(). With @BeforeMethod and @AfterMethod annotations on the appropriate setUp and tearDown methods in Spring's test classes (AbstractSingleSpringContextTests & others) the classes do behave the same whethere a new instance of each method is created or not. So, it works the same for both JUnit and TestNG.

If the test class requires a Spring injected prototype scoped bean, with the above annotations set, a new bean will be injected before every test method is invoked in the same or instances per-method of the test class.

So, I think my use case for requiring a new instance to be created by TestNG for every test method is not correct. However, I think TestNG optionally creating an instance per test method may be useful when working with junit based frameworks that may not be as amenable as. Spring. I cannot think of any right now though :)

Thank you
Monal
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=58311&messageID=115524#115524


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en
-~----------~----~----~----~------~----~------~--~---