> The @Tests in my test class(es) represent a sequence of steps in a
> workflow/use case that must be executed in a pre-determined order using the
> same WebDriver object (browser window).  I've set each class to run
> 'singleThreaded=true' and use the dependsOnMethods to chain the @Test
> methods *(sidenote: is there a less maintenance heavy way to chain
> dependent test cases --- say alphabetically by name?)*.

> In the past, I've used two approaches:

>    1. Each class creates it's own WebDriver object, where the class was
>    responsible for the setup/teardown of the driver (which launches a web
>    browser).  This process is fairly expensive to do for each class.
>    2. Implement a custom WebDriver factory that would return the driver
>    for the current thread Id (called in @BeforeClass).  This seemed to work
>    okay for the limited time I used it.

> I'm looking to learn/try Guice/DI to inject the correct WebDriver object
> into to each class based on test thread and *only* the test threads (rules
> out constructor injection?).  When a class runs, I'd like to inject the
> correct WebDriver based on the test thread (somehow).  This is what I'm
> still learning/trying to work out.

> Hopefully that made sense.

> 2011/10/5 Cédric Beust ♔ <ced...@beust.com>

>> Hi Jeff,

>> I'm not sure I see the problem with injecting in a multithreaded context
>> as long as you pay attention to how you access the injected resource...

>> But maybe I'm missing something?

>> --
>> Cédric

>> On Tue, Oct 4, 2011 at 3:53 PM, Jeff <predato...@gmail.com> wrote:

>>> Guice "Best Practices" recommends using constructor injection to create
>>> "immutable" objects.  This is great until the test class needs resources
>>> that are tied to TestNG test threads (unless I'm missing something).

>>> If I create a custom Guice Module/Provider to handle injecting
>>> MyPerThreadResource, I could use @Test method injection:

>>> @Test
>>> @Inject
>>> public void test1(MyPerThreadResource resource) {
>>>    // use resource
>>> }

>>> Or, similarly @BeforeClass method injection (assumes the class is marked
>>> as @Test(singleThreaded=true) ):

>>> @BeforeClass
>>> @Inject
>>> public void beforeClass(MyThreadResource resource) {
>>>    this.resource = resource;
>>> }

>>> I considered Field Injection at the test class level, but I don't
>>> think the Test Classes are being instantiated on the same thread used to run
>>> them.

>>> Is there a better way to tie resources to the test threads (particularly
>>> using DI)?

>>> --

>>> Jeff Vincent
>>> predato...@gmail.com
>>> See my LinkedIn profile at:
>>> http://www.linkedin.com/in/rjeffreyvincent
>>> I ♥ DropBox <http://db.tt/9O6LfBX> !!

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

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

> --
> Jeff Vincent
> predato...@gmail.com
> See my LinkedIn profile at:
> http://www.linkedin.com/in/rjeffreyvincent
> I ♥ DropBox <http://db.tt/9O6LfBX> !!