Compile generated code and execute it

[stephanenicolas]

Hi @cgruber ,

is it possible to compile generated code and execute it via compile-testing ?
I mean compile the code that an annotation processor created, and use the compiled classes ?

If not, how would you do ?

[tbroyer]

The way Dagger and Auto do it is using "integration tests": using the maven-invoker-plugin to spawn Maven projects (stored in src/it) and assert about their outcome (success, failure, etc.)
That however means you'll duplicate code between unit-tests using compile-testing and integration-tests using m-invoker-p.

[stephanenicolas]

Thx @tbroyer , I need a system like that.
Example in Auto (for future reference) : https://github.com/google/auto/blob/master/value/pom.xml

There is no pure gradle solution ?

[johncarl81]

I was looking for this feature in compile-testing too while I was evaluating it as a replacement for some testing code. Not finding the feature directly, I figured this feature was slightly out of scope for this library.

This is certainly possible using the underlying Java Compiler API (JSR 199 I think). Here's a quick and dirty example: https://gist.github.com/johncarl81/46306590cbdde5a3003f

Notice that I am calling an assertion against generated code:

TestTarget testTarget = (TestTarget) loader.loadClass("ProcessedTest").newInstance();
assertEquals("Hello", testTarget.get());

[stephanenicolas]

I like that @johncarl81 , I had implemented the strategy proposed by @tbroyer in a former project :
https://github.com/stephanenicolas/boundbox/tree/master/boundbox-library-integration-tests
(if this can help anyone).

And your approach @johncarl81, in the same project for unit testing the processor (at that time I didn't know about truth) :
https://github.com/stephanenicolas/boundbox/blob/master/boundbox-library/src/test/java/org/boundbox/processor/BoundBoxProcessorTest.java

I think both techniques are interesting, I need to sort out what are the advantages and drawbacks of each of them. Sure, it looks like having an integration-test project with sample like classes and their associated tests seems easier, but they ain't unit tests.

Thx all @tbroyer and @johncarl81 for your answers. I wish this issue can be useful to others.

@cgruber, you can probably close it, I am really not sure this kind of testing might fall into the scope of your lib as indicated by @johncarl81.

Btw, I am still amazed by the amount of help one can get in 4 hours only by posting an issue on GH. ;)
Hail to FOSS community !

[cgruber]

Yeah - we had requests for this sort of testing internally too, and found that such features were typically overwrought, and you just wanted to actually use the code in an integration test. They're not actually unit-tests, since you're testing the whole process of source -> compilation (wiht processing optionally) -> execution. That's an end-to-end test, albeit a small one. I'll close this.