Groovy 1.6 introduced the concept of AST transformations. The basic concepts of global and local AST transformations have already been described in a separate blog-post  and will not be part of this article.
Writing AST transformations and therefore modifying Groovy's compilation process is pretty easy. Depending on the type of AST transformation (local or global) groovyc will find ASTTransformation classes in its classpath and will apply them in the specified compilation phase (e.g. SEMANTIC_ANALYSIS).
So far so good. But if you are dealing with more complex AST transformations chances are you probably want to write unit tests that ensure the provided functionality.
The @Serializable Annotation
Let's consider the local AST transformation of a previous blog-post :
It implements the AST transformation for a @Serializable annotation that marks classes as serializable. The transformations adds the java.io.Serializable interface to the class definition. Note that the transformation class SerializableASTTransformation is written in Groovy and therefore needs to be compiled with groovyc.
Testing AST Transformations
The main question when dealing with AST transformations is how to test them properly.
Independent of the chosen implementation, a test workflow for AST transformations must cover the following steps:
1. Compile the AST transformation class + all dependent classes/annotations etc.
2. Compile the test cases using the previously compiled AST transformation classes
It is obvious that these two steps can't be done in a single compilation run. Using a single compilation run, whenever trying to compile either 1. or 2. will fail with a compilation error. Thus to test AST transformations a test workflow needs to be implemented that runs in two separate compilation runs.
The first possibility would be to let your IDE handle these two separate phases. In IntelliJ, Eclipse etc. it would be easy to establish a configuration where the AST transformation classes are bundled in a separate module which is compiled to a JAR during build time. That jar can than be used to execute test cases using the bundled AST transformations. I wont provide any details on this appraoch since it has a significant drawback: with this setup debugging AST transformations is not possible.
Since groovyc determines AST transformation classes we would need to execute groovyc in debug mode. Take a look at the following source snippet from Groovy's CompilationUnit:
Class ASTTransformationVisitor is the class that reads local and global AST transformations and adds them to the specified compilation phases, e.g. in the case of local AST transformations:
To sum up: we need another way to debug AST transformations.
A Custom GroovyClassLoader
Another possiblity - and this is the preferred approach - is to use a custom GroovyClassLoader which allows to programmatically add a list of AST transformations.
GContracts  is a Groovy extension that uses AST transformations to provide Design by Contract(tm) for Groovy. In order to built a reliable test suite two points were of importance:
1. Debugging support was absolutely necessary for building a library like GContracts
2. Tests need to be written really, really fast which implies small configuration and bootstrapping effort
In order to achieve these goals a base test class extending GroovyTestCase was implemented. BaseTestClass offers the most important utility methods to its descendants:
As can be seen in the code above, method setUp is used to create a custom GroovyClassLoader which allows specification of additional AST transformations at a specified compilation phase (in this case it is CompilationPhase.SEMANTIC_ANALYSIS). The classloader is used to create classes with transformations already applied.
Let us take a look at how the base test class can be extended by descendants:
This test class was directly copied from GContracts' test suite. It checks whether the so-called old variable behaves correctly for value types. Notice that property templateSourceCode just specifies a class template which is completed by createSourceCodeForTemplate using Groovy's GStringTemplateEngine .
create_instance_of is than used to directly get an instance of the class which is specified in the given source code string:
Alternatively, clients might use add_class_to_classpath to create an instance of the class object at first, splitting instance creation into two steps.
With this knowledge, a test case for the @Serializable annotation could look like this:
The beauty of this appraoch is that AST transfrormations can be debugged and can therefore be executed out of the chosen build management tool. This is possible due to splitting the overall compilation run into two independent runs: a static and a dynamic (using GroovyClassLoader at runtime) run.
In addition, using Groovy's GStringTemplateEngine, source code and the according class objects can be built at runtime which is a hughe performance boost in terms of test case writing time.