It is really a simple use case : our lib can add javadoc to a generated
class or not. To test it, I would create a nice mock with a partial mocking
of the emitJavadoc method with 0 expectations or at least one.

I don't wanna really on string output when testing an annotation processor.
I had some system like this for my previous annotation processor but it was
painful, I prefer to compile the generated classes now and use reflection
to assert the resulting class matches my expectations.

Our current project is BoundBox :
https://github.com/stephanenicolas/boundbox


2013/9/25 Jake Wharton <notifications@github.com>

> In src/main/java/com/squareup/javawriter/JavaWriter.java:
>
> > @@ -32,7 +32,7 @@
> >  import javax.lang.model.element.Modifier;
> >
> >  /** A utility class which aids in generating Java source files. */
> > -public final class JavaWriter implements Closeable {
> > +public class JavaWriter implements Closeable {
>
> It seems really odd to mock and test calls to this class. What project are
> you using it in? I would think you'd test calls at a higher level (e.g., to
> methods which then invoke this class) or at a lower level (e.g., the
> generated Java string/output).
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/square/javawriter/pull/25/files#r6578416>
> .
>



-- 
Stéphane *NICOLAS*,
*OCTO Technology*
Développeur & Consultant Android / Java
..........................................................
50, Avenue des Champs-Elysées
75008 Paris
+33 (0)6.26.32.34.09
www.octo.com - mobilite.octo.com
blog.octo.com - www.usievents.com
...........................................................