Annotation Transformer "global context" ?

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

Annotation Transformer "global context" ?

tarun3kumar

Hi,
When one implement the method
public void transform(ITest annotation, Class testClass, Constructor testConstructor, Method testMethod)
'annotation' represents a kind of local 'context' (local to the Method): the annotations characterize the Method itself (dependent groups, dependent methods, and so on)

But what about the Test itself, which could represent a 'global context' (excluded and included groups, classes, method names declared in a given xml testng file) ?

That could be useful especially if I want to modify annotations of a method only if a certain group or class has be mentioned (included / excluded) within my suite.xml file.

When transform() is called (for the first time from TestRunner.initMethod() withinTestRunner.init()), TestRunner.m_xmlTest has been valued and contains informations that could be exploited during the annotation transformer decision process.

So I would like an interface similar to ITest allowing me to access to the **declared** (declared within the xmltest file) list of (included / excluded) groups, classes, method). That interface would be a new argument passed to the 'transform' method.

Again, that interface would only access to the declared items in a testng suite xml file, not to the **calculated** list of included / excluded groups, classes, methods, since that computation  only takes place after the TestRunner initialization, and involves closure determinations (implying that TestRunner knows about all groups, classes, methods)

Actually, it already exists (kind of): ITestContext plays that role in the methods onStart or onFinish within a ITestListener... but, that kind of Listener is only called after TestRunner.init() (which has already called about 10 times the annotation transformers of methods involved): it is too late.

Concrete scenario (testng 5.3 or 5.4):
* I have a method 'm' which depend on another group 'g'
* In my  testng xml file, I declared that group 'g' as excluded
* If I make no annotation transformation, my method 'm' will be skipped (because "Method 'm' depends on nonexistent group", from org.testng.internal.Invoker.invokeTestMethods())
* If I want to remove that group dependency, I can do it through a annotation transformer (and 'm' will not be skipped), but I have no way to know if that group was declared excluded or not.

Does that make sense ? Is there already a way to do that ?
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=56773&messageID=112341#112341


--~--~---------~--~----~------------~-------~--~----~
 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: Annotation Transformer "global context" ?

tarun3kumar

Hi again,

One (ugly) way to work around the aforementioned issue is to use a custom TestRunnerFactory class, through the '-testrunfactory' command-line option.
That allows to memorize somewhere the TestRunner created, in order for an Annotation Transformer to get from that TestRunner the list of included/excluded group

However, when TestNG.createAndRunSuiteRunners() is called, it creates a SuiteRunner with a 'm_testRunnerFactory' which is still null (?!)

Which means TestNG privateMain() has done nothing about the '-testrunfactory' command-line option... : the result.run(arguments) does get the 'testrunfactory' argument (I checked: my class is correctly detected)... but does nothing with it!
(More specifically, it does not call TestNG.setTestRunnerFactoryClass(Class)... actually, that function seems to be never called at all anywhere in the testng java code...)
Is that a bug ? What I see is my ITestRunnerFactory implementation is detected but ignored...
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=56773&messageID=112349#112349


--~--~---------~--~----~------------~-------~--~----~
 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: Annotation Transformer "global context" ?

tarun3kumar

Hi (ter),

I confirm (regarding the '-testrunfactory' issue):
It only takes one line in the TestNG.configure() method to make TestNG take into account a user-defined TestRunnerFactory:
setTestRunnerFactoryClass((Class) cmdLineArgs.get(TestNGCommandLineArgs.TESTRUNNER_FACTORY_COMMAND_OPT));


I amend my previous message (regarding the 'global context' issue):
the Annotation Transformer can not ask to a TestRunner instance (memorized by a custom TestRunnerFactory), since it is during the init phase of the creation of that very TestRunner instance that the Annotation Transformer is called: The TestRunnerFactory can not memorized the TestRunner instance which is being build!

Which means... if one wants 'global context' about the current test when one wants to transform annotations on some methods... one must currently do:

1/ extends org.testng.TestNG by redefining:
main
privatemain (to create a 'MyTestNG instance)
configure (to add the missing line about TESTRUNNER_FACTORY_COMMAND_OPT)

2/ extends DefaultTestRunnerFactory into a 'MyDefaultTestRunnerFactory' and, at the beginning of newTestRunner(), before creating a TestRunner (which trigger all the 'Annotation Transformer' calls, it must :
2.1/ memorize itself
2.2/ do all the m_xmlMethodSelector initialization (normally done in TestRunner, to collect all testng xml declarations, which are precisely the 'global context' I wish to exploit when I must decide if a given 'Annotation Transformer' should do anything or not)
: that include to code again (copy) the createGroups() functions of TestRunner into the 'MyDefaultTestRunnerFactory'... (sigh...)

3/ Code a MyAnnotationTransformer  which will ask to the MyDefaultTestRunnerFactory memorized in 2.1 for the (i.e.) getExcludedGroups() list in order to (again i.e.) remove any group listed as dependent a given method method if that group has been declared has excluded...

4/ call TestNG through
'java mypackage.MyTestNG -testrunfactory mypackage.MyDefaultTestRunnerFactory -listener mypackage.MyAnnotationTransformer -sourcedir src config/testng.xml'

And it works... but that is one **ugly** workaround!

Sooo...
a/ Could you add the missing line to TestNG.configure() ?
b/ Could you allow an Annotation Transformer to access the list of groups and classes included/excluded ?
(like those listed in XmlMethodSelector, which is precisely based on 'the specification given in testng.xml' -- that comes directly from the javadoc of XmlMethodSelector.java --)
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=56773&messageID=112402#112402


--~--~---------~--~----~------------~-------~--~----~
 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: Annotation Transformer "global context" ?

Cédric Beust ♔


On 1/4/07, Chaffiol <[hidden email]> wrote:


Sooo...
a/ Could you add the missing line to TestNG.configure() ?
b/ Could you allow an Annotation Transformer to access the list of groups and classes included/excluded ?
(like those listed in XmlMethodSelector, which is precisely based on 'the specification given in testng.xml' -- that comes directly from the javadoc of XmlMethodSelector.java --)

I could pass you the XmlTest object, which gives you access to this information (and also to the enclosing XmlSuite).

Would this help?

--
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: Annotation Transformer "global context" ?

Alexandru Popescu ☀
On 1/4/07, C�dric Beust   <[hidden email]> wrote:

>
>
> On 1/4/07, Chaffiol <[hidden email]> wrote:
> >
> >
> > Sooo...
> > a/ Could you add the missing line to TestNG.configure() ?
> > b/ Could you allow an Annotation Transformer to access the list of groups
> and classes included/excluded ?
> > (like those listed in XmlMethodSelector, which is precisely based on 'the
> specification given in testng.xml' -- that comes directly from the javadoc
> of XmlMethodSelector.java --)
>
> I could pass you the XmlTest object, which gives you access to this
> information (and also to the enclosing XmlSuite).
>
> Would this help?
>

If we start doing this, I think we must publish a read-only interface
to XmlTest, because otherwise things may get really complex.

./alex
--
.w( the_mindstorm )p.
  TestNG co-founder
EclipseTestNG Creator

> --
> 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: Annotation Transformer "global context" ?

tarun3kumar

Hi Cedric, Alex,

On the secondary subject:
could you confirm that the '-testrunfactory' in a testng command line is currently ignored ? (tesng5.4)

On the main topic:
XmlTest does contain informations which are part of a 'global context' useful for Annotation Transformers.
However, Alex is right, an interface should be defined for such a context, like ITestContext used for Listener.
That interface (i.e. 'ITestngContext' ?) would allow to access to various elements declared in a testng.xml, **but could also evolve**, should users pinpoints other useful global informations for a Annotation Transformer to base its decision upon.
That means XmlTest should not implement that interface.

Again, a 'global context' for Annotation Transformer should contain 'declarative data', since the computed data like the final list of groups or methods used are based upon annotations (which are precisely transformed!), and based upon a 'closure computation' mechanism (especially through MethodHelper.findGroupTransitiveClosure(), for example)

That brings up a remark: 'closure' can led to surprising behavior :
If I have 2 groups 'g1' and 'g2', and one of the methods ('m') of 'g1' depends on 'g2', I have only to declare in my testng.xml <groups><run><include name = "g1" /></run></groups> for both groups to be processed.
So far so good.
But if I decide to exclude g2 by adding an 'exclude' element, like in:
<groups><run><include name = "g1" /><exclude name = "g2" /></run></groups>
g1 and g2 will still be processed! (because of the 'closure' mechanism)
If I only exclude g2 (<groups><run><exclude name = "g2" /></run></groups>), the methods of g1 will be skipped (because "Method 'm' depends on nonexistent group 'g2', from org.testng.internal.Invoker.invokeTestMethods())

Now, I am not asking for any kind of change here (I am sure those scenarios have been discussed in the past and that the current behavior is the most efficient one)
However, my point is: 'closure' does not appear anywhere in 'http://testng.org/doc/documentation-main.html'.
So the remark follows as: "It might be interesting to mention in the testng documentation the existence of a 'closure mechanism' in the computation of final groups, classes or methods involved in a test and to describe an example or two illustrating that mechanism".

Best regards,
--
Daniel
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=56773&messageID=112576#112576


--~--~---------~--~----~------------~-------~--~----~
 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: Annotation Transformer "global context" ?

Alexandru Popescu ☀

On 1/5/07, Chaffiol <[hidden email]> wrote:
>
> Hi Cedric, Alex,
>
> On the secondary subject:
> could you confirm that the '-testrunfactory' in a testng command line is currently ignored ? (tesng5.4)
>

I don't think so, but I must check. I will get back to you later.

> On the main topic:
> XmlTest does contain informations which are part of a 'global context' useful for Annotation Transformers.
> However, Alex is right, an interface should be defined for such a context, like ITestContext used for Listener.
> That interface (i.e. 'ITestngContext' ?) would allow to access to various elements declared in a testng.xml, **but could also evolve**, should users pinpoints other useful global informations for a Annotation Transformer to base its decision upon.
> That means XmlTest should not implement that interface.
>

I am not sure what do you mean by the above.  I don't think it is
important for an user who will be implementing the exposed interface
as long as it serves correctly. And for the moment, if I got your
message right XmlTest fits perfectly the needed interface.

> Again, a 'global context' for Annotation Transformer should contain 'declarative data', since the computed data like the final list of groups or methods used are based upon annotations (which are precisely transformed!), and based upon a 'closure computation' mechanism (especially through MethodHelper.findGroupTransitiveClosure(), for example)
>

Just to clarify: are you saying that the exposed context should offer
access to the data gather from code declarations and not the
information computed internally in order to detemine the invocation
graph. Is this correct? If so, then yes I agree.

> That brings up a remark: 'closure' can led to surprising behavior :
> If I have 2 groups 'g1' and 'g2', and one of the methods ('m') of 'g1' depends on 'g2', I have only to declare in my testng.xml <groups><run><include name = "g1" /></run></groups> for both groups to be processed.
> So far so good.
> But if I decide to exclude g2 by adding an 'exclude' element, like in:
> <groups><run><include name = "g1" /><exclude name = "g2" /></run></groups>
> g1 and g2 will still be processed! (because of the 'closure' mechanism)
> If I only exclude g2 (<groups><run><exclude name = "g2" /></run></groups>), the methods of g1 will be skipped (because "Method 'm' depends on nonexistent group 'g2', from org.testng.internal.Invoker.invokeTestMethods())
>
> Now, I am not asking for any kind of change here (I am sure those scenarios have been discussed in the past and that the current behavior is the most efficient one)
> However, my point is: 'closure' does not appear anywhere in 'http://testng.org/doc/documentation-main.html'.
> So the remark follows as: "It might be interesting to mention in the testng documentation the existence of a 'closure mechanism' in the computation of final groups, classes or methods involved in a test and to describe an example or two illustrating that mechanism".
>

Please let us know what exactly you should include in the docs and the
text and we will make sure it will get there. Thanks.

./alex
--
.w( the_mindstorm )p.
  TestNG co-founder
EclipseTestNG Creator

> Best regards,
> --
> Daniel
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=56773&messageID=112576#112576
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
 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: Annotation Transformer "global context" ?

tarun3kumar

>> That means XmlTest should not implement that interface.
> I am not sure what do you mean by the above. I don't think it is important for an user who will be implementing the exposed interface as long as it serves correctly. And for the moment, if I got your message right XmlTest fits perfectly the needed interface.

I agree... I meant that the services of the new interface could not necessarily be limited to those displayed by XmlTest. But the services of XmlTest do indeed fit the bill for now.

> Just to clarify: are you saying that the exposed context should offer access to the data gather from code declarations and not the information computed internally in order to determine the invocation graph. Is this correct? If so, then yes I agree.

I am saying just that indeed:
the "information computed internally in order to determine the invocation graph" is computed based on Annotations... and since an Annotation Transformers alters those annotations, it also alters the resulting "internally computed informations": hence those "internally computed informations" are not eligible as a global context which is meant to be given to the 'Annotation Transformer' process **before** it begins.

> Please let us know what exactly you should include in the docs and the text and we will make sure it will get there. Thanks.

After http://testng.org/doc/documentation-main.html#exclusions (5.3), you could add a link to a new section located just after http://testng.org/doc/documentation-main.html#dependent-methods

That section would go something like:
==== Invocation graph ====
The number and order of classes and methods which are indeed processed depends on:
- the nature of the test (that is on the testng annotation put on each method or class)
- the specification of the test (that is the testng.xml)

A closure mechanism will be apply to the specification of the test (testng.xml) and combined with all the annotations found in testng classes, in order to compute the order and number of methods actually processed or skipped.

To give a concrete example of that closure effect, suppose that:
- the nature of your test is one class, two methods m1 (part of a group 'g1' and dependent on a group 'g2') and m2 (part of group 'g2')
- the specification of your test is:
  * <groups><run><include name = "g1" /></run></groups> => both groups will be processed because the closure mechanism will detect the dependency of m1 on the group g2.
  * <groups><run><include name = "g1" /><exclude name = "g2" /></run></groups> => both groups are STILL processed: the 'exclude' specification is less important that the 'include' one, and the closure mechanism is based first on the 'include' directive. If 'g2' has already being computed as "to be included", the 'exclude' specification will not modify that result.
  * <groups><run><exclude name = "g2" /></run></groups> => m1 will be skipped (no group will be processed) since m1 depends on 'nonexistent' group 'g2' ('nonexistent' means 'not included by the closure mechanism')
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=56773&messageID=112640#112640


--~--~---------~--~----~------------~-------~--~----~
 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: Annotation Transformer "global context" ?

Cédric Beust ♔


On 1/5/07, Chaffiol <[hidden email]> wrote:

>> That means XmlTest should not implement that interface.
> I am not sure what do you mean by the above. I don't think it is important for an user who will be implementing the exposed interface as long as it serves correctly. And for the moment, if I got your message right XmlTest fits perfectly the needed interface.

I agree... I meant that the services of the new interface could not necessarily be limited to those displayed by XmlTest. But the services of XmlTest do indeed fit the bill for now.

At the moment where the annotation transformers are run, very little is known on the code base yet, so it's hard to pass more than the content of the current testng.xml file being run to these transformers, which is what XmlTest achieves.

I'll take care of it, but I'll probably have to create a new interface IAnnotationTransformer2:

public interface IAnnotationTransformer2 {

  public void transform(XmlTest xmlTest, ITest annotation, Class testClass,
      Constructor testConstructor, Method testMethod);

}

--
Cedric


> Just to clarify: are you saying that the exposed context should offer access to the data gather from code declarations and not the information computed internally in order to determine the invocation graph. Is this correct? If so, then yes I agree.

I am saying just that indeed:
the "information computed internally in order to determine the invocation graph" is computed based on Annotations... and since an Annotation Transformers alters those annotations, it also alters the resulting "internally computed informations": hence those "internally computed informations" are not eligible as a global context which is meant to be given to the 'Annotation Transformer' process **before** it begins.

> Please let us know what exactly you should include in the docs and the text and we will make sure it will get there. Thanks.

After http://testng.org/doc/documentation-main.html#exclusions (5.3), you could add a link to a new section located just after http://testng.org/doc/documentation-main.html#dependent-methods

That section would go something like:
==== Invocation graph ====
The number and order of classes and methods which are indeed processed depends on:
- the nature of the test (that is on the testng annotation put on each method or class)
- the specification of the test (that is the testng.xml)

A closure mechanism will be apply to the specification of the test (testng.xml) and combined with all the annotations found in testng classes, in order to compute the order and number of methods actually processed or skipped.

To give a concrete example of that closure effect, suppose that:
- the nature of your test is one class, two methods m1 (part of a group 'g1' and dependent on a group 'g2') and m2 (part of group 'g2')
- the specification of your test is:
  * <groups><run><include name = "g1" /></run></groups> => both groups will be processed because the closure mechanism will detect the dependency of m1 on the group g2.
  * <groups><run><include name = "g1" /><exclude name = "g2" /></run></groups> => both groups are STILL processed: the 'exclude' specification is less important that the 'include' one, and the closure mechanism is based first on the 'include' directive. If 'g2' has already being computed as "to be included", the 'exclude' specification will not modify that result.
  * <groups><run><exclude name = "g2" /></run></groups> => m1 will be skipped (no group will be processed) since m1 depends on 'nonexistent' group 'g2' ('nonexistent' means 'not included by the closure mechanism')
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=56773&messageID=112640#112640


--
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: Annotation Transformer "global context" ?

Alexandru Popescu ☀
On 1/5/07, C dric Beust   <[hidden email]> wrote:

>
>
> On 1/5/07, Chaffiol <[hidden email]> wrote:
> >
> > >> That means XmlTest should not implement that interface.
> > > I am not sure what do you mean by the above. I don't think it is
> important for an user who will be implementing the exposed interface as long
> as it serves correctly. And for the moment, if I got your message right
> XmlTest fits perfectly the needed interface.
> >
> > I agree... I meant that the services of the new interface could not
> necessarily be limited to those displayed by XmlTest. But the services of
> XmlTest do indeed fit the bill for now.
>
> At the moment where the annotation transformers are run, very little is
> known on the code base yet, so it's hard to pass more than the content of
> the current testng.xml file being run to these transformers, which is what
> XmlTest achieves.
>
> I'll take care of it, but I'll probably have to create a new interface
> IAnnotationTransformer2:
>
> public interface IAnnotationTransformer2 {
>
>   public void transform(XmlTest xmlTest, ITest annotation, Class testClass,
>       Constructor testConstructor, Method testMethod);
>
> }
>

I know we should always look for the backward compatibility, but I am
not sure if they are so many users to justify the introduction of a
new interface. Also, just to be sure we are on the same page: the API
will not expose XmlTest but an IXmlTest that is read-only.

./alex
--
.w( the_mindstorm )p.
  TestNG co-founder
EclipseTestNG Creator


> --
> Cedric
>
>
> > > Just to clarify: are you saying that the exposed context should offer
> access to the data gather from code declarations and not the information
> computed internally in order to determine the invocation graph. Is this
> correct? If so, then yes I agree.
> >
> > I am saying just that indeed:
> > the "information computed internally in order to determine the invocation
> graph" is computed based on Annotations... and since an Annotation
> Transformers alters those annotations, it also alters the resulting
> "internally computed informations": hence those "internally computed
> informations" are not eligible as a global context which is meant to be
> given to the 'Annotation Transformer' process **before** it begins.
> >
> > > Please let us know what exactly you should include in the docs and the
> text and we will make sure it will get there. Thanks.
> >
> > After
> http://testng.org/doc/documentation-main.html#exclusions
> (5.3), you could add a link to a new section located just after
> http://testng.org/doc/documentation-main.html#dependent-methods
> >
> > That section would go something like:
> > ==== Invocation graph ====
> > The number and order of classes and methods which are indeed processed
> depends on:
> > - the nature of the test (that is on the testng annotation put on each
> method or class)
> > - the specification of the test (that is the testng.xml)
> >
> > A closure mechanism will be apply to the specification of the test
> (testng.xml) and combined with all the annotations found in testng classes,
> in order to compute the order and number of methods actually processed or
> skipped.
> >
> > To give a concrete example of that closure effect, suppose that:
> > - the nature of your test is one class, two methods m1 (part of a group
> 'g1' and dependent on a group 'g2') and m2 (part of group 'g2')
> > - the specification of your test is:
> >   * <groups><run><include name = "g1" /></run></groups> => both groups
> will be processed because the closure mechanism will detect the dependency
> of m1 on the group g2.
> >   * <groups><run><include name = "g1" /><exclude name = "g2"
> /></run></groups> => both groups are STILL processed: the 'exclude'
> specification is less important that the 'include' one, and the closure
> mechanism is based first on the 'include' directive. If 'g2' has already
> being computed as "to be included", the 'exclude' specification will not
> modify that result.
> >   * <groups><run><exclude name = "g2" /></run></groups> => m1 will be
> skipped (no group will be processed) since m1 depends on 'nonexistent' group
> 'g2' ('nonexistent' means 'not included by the closure mechanism')
> >
> ---------------------------------------------------------------------
> > Posted via Jive Forums
> >
> http://forums.opensymphony.com/thread.jspa?threadID=56773&messageID=112640#112640
> >
> >
> > --
> > 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: Annotation Transformer "global context" ?

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

I agree with Alex answer: to pass 'XmlTest' seems to me very dubious:
I do not care that " it's hard to pass more than the content of the current testng.xml file being run to these transformers "
If ever one day other informations coming from other sources than the XmlTest (testng.xml) are worthy to be passed to an Annotation Transformer, you would be able to complete the services of an Interface, but you would not be able to add services to XmlTest (which only represents testng.xml)

To amend Alex's proposition, I would like an different name than IXmlTest: than name introduces a semantic link between XmlTest (testng.xml) and what is passed to an Annotation Transformer.
A better name would be ITestngContext, because it is a context (and 'testng' to avoid any confusion with ITestContext, context of a test **after** all test initializations and transformations, and used by Listener or Reporter)
Again, the fact that ITesngContext basically displays (for now) the services of XmlTest is of no importance.

For instance, (this is just a 'silly' example), suppose I want to base my annotation transformations on the very moment when the testng has been started.
I could, in my annotation transformer code, use a getTime() function, but I have no idea how long other annotation transformers have take time to process themselves.
So one could imagine that the testng code would create the ITestngContext at a very early time during its execution, initialize it with the starting time, then would read testng.xml and call the various Annotation Transformer.
That new service (getStartingTime()) could be easely added to a ITestngContext interface. It would be more ackward to add it to an IXmlTest interface since a 'starting time' has nothing to do with an 'xml file' anyway... and it would be impossible to add such a service to the object XmlTest.
Cedric, Do you see my point now ?

Best regards,
---
Daniel
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=56773&messageID=113049#113049


--~--~---------~--~----~------------~-------~--~----~
 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
-~----------~----~----~----~------~----~------~--~---