[Checkers] Testing Approach Proposal

[Mahmood Ali]

Hi guys,

Currently we cannot do any unit testing due to the way the compiler  
works. I have been thinking about this lately, and came up with two  
approaches.  Both approaches require an input java file
(consider one specified as 'class Test { void test()  
{ Lists.asList("m", "n"); } }').  We can do one of the following:

1. Using textual expected type.
The checker tester would specify in a different file the expected type  
for some trees and their corresponding types.  To test the Interned  
Checker, one would specify
test():Lists.asList("m", "n")		List<@Interned String>		// only check  
Lists.asList() within method test
*:List.asList("m", "n")			List<@Interned String>		// check  
List.asList() within all methods

This is a very limiting test, as it would only test  
AnnotatedTypeFactory.getAnnotatedType().  However, implementing this  
approach is somewhat straight-forward and takes care of a lot of the  
cases.

2. A specialized visitor in code
We could have a specialized test suite.  To test the previous case one  
would write something along the lines:
class MyTest extends SpecializedTest {
   AnnotatedTypeFactory createFactory(ProcessingEnvironment env,  
CompilationUnitTree root) {
     return new InternedAnnotatedTypeFactory(env, root);
   }

   @TestForTree("*:List.asList("m", "n")")
   void testTypeInference(Tree tree) {
     AnnotatedTypeMirror type = factory.getAnnotatedType(tree);
     assertEquals(type.toString(), "List<@Interned String>");
   }
}

SpecializedTest class would have a specialized tree visitor that  
invoke the test method for tree found in TestForTree.  A method would  
only be called on the tree specified in @TestForTree.

This allows for greater testing as one can "unit" test any they like,  
without too much boilerplate code.


What do you think?

- Mahmood