Annotation Transformers in TestNG: The Sweet Spot for Annotations?

Posted by Rob Thornton on Oct 31, 2006

Sections

Architecture & Design,

Development,

Operations & Infrastructure

Topics

Java ,

Configuration Management ,

Programming

Tags

Annotations ,

TestNG ,

Testing

In the continuing search to find the balance between XML and annotations, TestNG has introduced the concept of annotation transformers.  Conceived of by TestNG co-founder Alexandru Popescu (who is also InfoQ's Chief Architect), an annotation transformer is code that will override the behavior of annotations elsewhere in your project. This allows you to modify your annotation without using XML and without recompiling your source. You will have to recompile your annotation transformers if you change them.

Cedric Beust details the idea of annotation transformers and compares the pros and cons of XML vs annotations. His summary of XML vs annotations is:

...annotations allow you to put your configuration system close to the Java source it applies to, but changing it requires Java knowledge and a recompilation. On the other hand, XML files are usually easy to modify and they can be reread at runtime (sometimes even without relaunching your application), but they are very verbose and the edition can be error prone.

Beust refers to an idea he had back in 2004 of using XML to override annotations as something that is unlikely to take off, for good reason. Instead, TestNG 5.3 includes annotations transformers, which allow developers to programmatically override annotations, via the IAnnotationTransformer interface.  An example of their use is to override the number of times a test is invoked.  For example:

public class Mytest {
 @Test(invocationCount = 10)
 public void verify() {
   // ...
 }
}

This test annotation could be transformed to change the invocation count to a higher number:

public class MyTransformer implements IAnnotationTransformer {
 public void transform(ITest annotation, Class testClass,
                       Constructor testConstructor, Method testMethod)   {
   if ("verify".equals(testMethod.getName())) {
     annotation.setInvocationCount(15);
   }
 }
}

1. Back to top

   Other example

   by Alex Popescu

   Another example (extracted from the TestNG mailing list): set a default timeout value for all @Test methods, without having to modify this annotation argument in all existing @Test methods. And I am pretty sure there are other good example for which the code based annotation overridding is better than the XML way.
   
   However, I am very interested to see more usage scenarios from our users. It took me and Cedric a while to figure out the details of this feature, so we are looking forward for possible ways to improve it.
   
   ./alex
   --
   .w( the_mindstorm )p.
   TestNG co-founder
   EclipseTestNG Creator

   Reply

2. Back to top

   Re: Other example

   by Cedric Beust

   To give full credit, the current design is entirely Alexandru's idea.
   
   On an unrelated note, it's kind of scary to be pointed back to a blog entry I posted more than two years ago and that I didn't even remember writing. I stand by what I said back then, though :-)
   
   --
   Cedric

   Reply

3. Back to top

   credits

   by Floyd Marinescu

   Thank for pointing that out, Alex was too modest to tell us. :) We've modified the intro to mention this. It adds good context to post to point out the origins of stuff like this.

   Reply

• Older >