instantiating tests

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

instantiating tests

Hani Suleiman

Something which has come up time and again is the ability for custom  
code to be involved in some way in the instantiation of tests.

Right now TestNG eventually winds its way to either call  
Class.newInstance() on a class or Constructor.newInstance(), and it'd  
be great if we could hook into this mechanism in some way to allow  
for custom test object instantiation, via custom object factories.

If you're not convinced, here are some uses:

- Return instrumented classes (maybe even through bytecode weaving)  
to add in any AOP behaviour
- Use Spring (or any other IoC container) to automatically wire up tests
- Allow for custom annotation processing with behaviour injected,  
where the object factory would return a custom instance based on the  
annotation

In terms of the API, I'm thinking something like:

public interface IObjectFactory
{
   Object newInstance(Class c, Object... params)
}

The default impl would obviously behave exactly as the current one.

The only real issue is how best to hook in an implementation, this  
can be either via command line:

-objectfactory com.foo.bar.PooFactory

Or an annotation:

@ObjectFactory
public IObjectFactory create()
{
   return new SpringObjectFactory(...);
}

With checks to ensure that only one method can have this annotation  
in the project.

Thoughts?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "testng-dev" 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-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: instantiating tests

Cédric Beust ♔
+1.

Another example of instrumented class that could be returned would be one where the code has been heavily interlaced with Thread.yield() statements, making it easier to surface thread safety bugs.

--
Cedric

On 3/6/07, Hani Suleiman <[hidden email]> wrote:

Something which has come up time and again is the ability for custom
code to be involved in some way in the instantiation of tests.

Right now TestNG eventually winds its way to either call
Class.newInstance () on a class or Constructor.newInstance(), and it'd
be great if we could hook into this mechanism in some way to allow
for custom test object instantiation, via custom object factories.

If you're not convinced, here are some uses:

- Return instrumented classes (maybe even through bytecode weaving)
to add in any AOP behaviour
- Use Spring (or any other IoC container) to automatically wire up tests
- Allow for custom annotation processing with behaviour injected,
where the object factory would return a custom instance based on the
annotation

In terms of the API, I'm thinking something like:

public interface IObjectFactory
{
   Object newInstance(Class c, Object... params)
}

The default impl would obviously behave exactly as the current one.

The only real issue is how best to hook in an implementation, this
can be either via command line:

-objectfactory com.foo.bar.PooFactory

Or an annotation:

@ObjectFactory
public IObjectFactory create()
{
   return new SpringObjectFactory(...);
}

With checks to ensure that only one method can have this annotation
in the project.

Thoughts?





--
Cédric
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "testng-dev" 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-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: instantiating tests

Jessek
Contrary to my ill-informed belief some form of mix-ins do appear to
be more easily possible than I had thought. At least cglib made it
very easy when I experimented with it recently. Though this is
probably obvious to everyone already and I'm speaking a little above
my dev-grade so I'll quietly slink away now.. But I like it of course.
(as does Alexandru if I remember correctly )

On 3/6/07, Cédric Beust ♔ <[hidden email]> wrote:

> +1.
>
> Another example of instrumented class that could be returned would be one
> where the code has been heavily interlaced with Thread.yield() statements,
> making it easier to surface thread safety bugs.
>
> --
>  Cedric
>
> On 3/6/07, Hani Suleiman <[hidden email]> wrote:
> >
> > Something which has come up time and again is the ability for custom
> > code to be involved in some way in the instantiation of tests.
> >
> > Right now TestNG eventually winds its way to either call
> > Class.newInstance () on a class or Constructor.newInstance(), and it'd
> > be great if we could hook into this mechanism in some way to allow
> > for custom test object instantiation, via custom object factories.
> >
> > If you're not convinced, here are some uses:
> >
> > - Return instrumented classes (maybe even through bytecode weaving)
> > to add in any AOP behaviour
> > - Use Spring (or any other IoC container) to automatically wire up tests
> > - Allow for custom annotation processing with behaviour injected,
> > where the object factory would return a custom instance based on the
> > annotation
> >
> > In terms of the API, I'm thinking something like:
> >
> > public interface IObjectFactory
> > {
> >    Object newInstance(Class c, Object... params)
> > }
> >
> > The default impl would obviously behave exactly as the current one.
> >
> > The only real issue is how best to hook in an implementation, this
> > can be either via command line:
> >
> > -objectfactory com.foo.bar.PooFactory
> >
> > Or an annotation:
> >
> > @ObjectFactory
> > public IObjectFactory create()
> > {
> >    return new SpringObjectFactory(...);
> > }
> >
> > With checks to ensure that only one method can have this annotation
> > in the project.
> >
> > Thoughts?
> >
> >
> >
>
>
>
> --
> Cédric
>  >
>


--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "testng-dev" 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-dev?hl=en
-~----------~----~----~----~------~----~------~--~---