Question

我正在尝试使用java注释处理器。我能够使用“JavaCompiler”编写集成测试（事实上我现在正在使用“hickory”）。我可以运行编译过程并分析输出。问题：即使我的注释处理器中没有任何代码，单个测试也会运行大约半秒钟。这在TDD风格中使用它太长了。

嘲笑依赖关系对我来说似乎很难（我必须模拟整个“javax.lang.model.element”包）。有人成功为注释处理器（Java 6）编写单元测试吗？如果不是......你的方法是什么？

Answer 1

这是一个老问题，但似乎注释处理器测试的状态没有变得更好，所以我们今天发布了Compile Testing。最好的文档在package-info.java中，但一般的想法是，当使用注释处理器运行时，有一个流畅的API用于测试编译输出。例如，

ASSERT.about(javaSource())
    .that(JavaFileObjects.forResource("HelloWorld.java"))
    .processedWith(new MyAnnotationProcessor())
    .compilesWithoutError()
    .and().generatesSources(JavaFileObjects.forResource("GeneratedHelloWorld.java"));

测试处理器生成的文件是否匹配GeneratedHelloWorld.java（类路径上的黄金文件）。您还可以测试处理器是否产生错误输出：

JavaFileObject fileObject = JavaFileObjects.forResource("HelloWorld.java");
ASSERT.about(javaSource())
    .that(fileObject)
    .processedWith(new NoHelloWorld())
    .failsToCompile()
    .withErrorContaining("No types named HelloWorld!").in(fileObject).onLine(23).atColumn(5);

这显然比模拟简单得多，与典型的集成测试不同，所有输出都存储在内存中。

Answer 2

你是正确的嘲笑注释处理API（使用像easymock这样的模拟库）是很痛苦的。我试过这种方法，它很快崩溃了。您必须设置许多方法调用期望。测试变得无法维持。

基于状态的测试方法对我很有帮助。我必须实现javax.lang.model.* API I needed for my tests的部分内容。（那只是<350行代码。）

这是启动javax.lang.model对象的测试的一部分。在设置之后，模型应该与Java编译器实现处于相同的状态。

DeclaredType typeArgument = declaredType(classElement("returnTypeName"));
DeclaredType validReturnType = declaredType(interfaceElement(GENERATOR_TYPE_NAME), typeArgument);
TypeParameterElement typeParameter = typeParameterElement();
ExecutableElement methodExecutableElement = Model.methodExecutableElement(name, validReturnType, typeParameter);

静态工厂方法在实现javax.lang.model。*类的类Model中定义。例如declaredType。（所有不受支持的操作都会抛出异常。）

public static DeclaredType declaredType(final Element element, final TypeMirror... argumentTypes) {
    return new DeclaredType(){
        @Override public Element asElement() {
            return element;
        }
        @Override public List<? extends TypeMirror> getTypeArguments() {
            return Arrays.asList(argumentTypes);
        }
        @Override public String toString() {
            return format("DeclareTypeModel[element=%s, argumentTypes=%s]",
                    element, Arrays.toString(argumentTypes));
        }
        @Override public <R, P> R accept(TypeVisitor<R, P> v, P p) {
            return v.visitDeclared(this, p);
        }
        @Override public boolean equals(Object obj) { throw new UnsupportedOperationException(); }
        @Override public int hashCode() { throw new UnsupportedOperationException(); }

        @Override public TypeKind getKind() { throw new UnsupportedOperationException(); }
        @Override public TypeMirror getEnclosingType() { throw new UnsupportedOperationException(); }
    };
}

测试的其余部分验证了被测试类的行为。

Method actual = new Method(environment(), methodExecutableElement);
Method expected = new Method(..);
assertEquals(expected, actual);

您可以查看source code of the Quickcheck @Samples and @Iterables source code generator tests。（代码不是最优的.Session类有许多参数，而且参数类没有在自己的测试中测试，而是作为方法测试的一部分。尽管如此，它应该说明方法。）

VielGlück！

Answer 3

jOOR是一个小型Java反射库，它还提供对javax.tool.JavaCompiler中内存中Java编译API的简化访问。我们在单元测试jOOQ's annotation processors中添加了对此的支持。您可以像这样轻松编写单元测试：

@Test
public void testCompileWithAnnotationProcessors() {
    AProcessor p = new AProcessor();

    try {
        Reflect.compile(
            "org.joor.test.FailAnnotationProcessing",
            "package org.joor.test; " +
            "@A " +
            "public class FailAnnotationProcessing { " +
            "}",
            new CompileOptions().processors(p)
        ).create().get();
        Assert.fail();
    }
    catch (ReflectException expected) {
        assertFalse(p.processed);
    }
}

The above example has been taken from this blog post

Answer 4

选项是将所有测试捆绑在一个类中。对于一组给定的测试，编译等的半秒不是一个常数，我认为测试的实际测试时间是可以的。

Answer 5

我使用了http://hg.netbeans.org/core-main/raw-file/default/openide.util.lookup/test/unit/src/org/openide/util/test/AnnotationProcessorTestUtils.java虽然这是基于java.io.File的简单，但是你抱怨的性能开销也是如此。

Thomas建议嘲笑整个JSR 269环境会导致纯粹的单元测试。您可能希望编写更多的集成测试来检查您的处理器如何在javac中实际运行，从而更好地保证它是正确的，但只是想避免使用磁盘文件。这样做会要求你编写一个模拟JavaFileManager，遗憾的是它并不像看起来那么容易，我没有方便的例子，但是你不需要模仿Element接口等其他东西。

Answer 6

我处于类似的情况，所以我创建了Avatar库。它不会给你一个没有编译的纯单元测试的性能，但如果使用得当，你不应该看到很多性能损失。

Avatar允许您编写源文件，对其进行注释，并将其转换为单元测试中的元素。这允许您对使用Element对象的测试方法和类进行单元化，而无需手动调用javac。

Answer 7

我前段时间遇到了同样的问题，发现了这个问题。虽然提供的其他答案都不错，但我觉得仍有改进的空间。根据此问题的其他答案，我创建了 Elementary，这是一套 JUnit 5 扩展，可为单元测试提供真正的注释处理环境。

大多数库通过运行注释处理器来测试它们。但是，大多数注释处理器都非常复杂，并被分解为更细粒度的组件。通过运行注释处理器来测试单个组件是不可行的。相反，我们为这些测试提供了注释处理环境。

以下代码片段说明了如何测试 Lint 组件：

import com.karuslabs.elementary.junit.Cases;
import com.karuslabs.elementary.junit.Tools;
import com.karuslabs.elementary.junit.ToolsExtension;
import com.karuslabs.elementary.junit.annotations.Case;
import com.karuslabs.elementary.junit.annotations.Introspect;
import com.karuslabs.utilitary.type.TypeMirrors;

@ExtendWith(ToolsExtension.class)
@Introspect
class ToolsExtensionExampleTest {

    Lint lint = new Lint(Tools.typeMirrors());
    
    @Test
    void lint_string_variable(Cases cases) {
        var first = cases.one("first");
        assertTrue(lint.lint(first));
    }
    
    @Test
    void lint_method_that_returns_string(Cases cases) {
        var second = cases.get(1);
        assertFalse(lint.lint(second));
    }
    
    @Case("first") String first;
    @Case String second() { return "";}
    
}

class Lint {
    
    final TypeMirrors types;
    final TypeMirror expectedType;
    
    Lint(TypeMirrors types) {
        this.types = types;
        this.expectedType = types.type(String.class);
    }
    
    public boolean lint(Element element) {
        if (!(element instanceof VariableElement)) {
            return false;
        }
        
        var variable = (VariableElement) element;
        return types.isSameType(expectedType, variable.asType());
    }
    
}

通过用 @Introspect 注释测试类，用 @Case 注释测试用例，我们可以在与测试相同的文件中声明测试用例。测试用例的相应 Element 表示可以通过使用 Cases 的测试进行检索。

如果有人感兴趣，我写了一篇文章，The Problem with Annotation Processors 详细介绍了单元测试注释处理器的问题。

如何为java注释处理器编写自动化单元测试？

7 个答案: