Class CompilationTestHelper

java.lang.Object
com.google.errorprone.CompilationTestHelper

@CheckReturnValue public class CompilationTestHelper extends Object
Helps test Error Prone bug checkers and compilations.
  • Method Details

    • newInstance

      public static CompilationTestHelper newInstance(ScannerSupplier scannerSupplier, Class<?> clazz)
      Returns a new CompilationTestHelper.
      Parameters:
      scannerSupplier - the ScannerSupplier to test
      clazz - the class to use to locate file resources
    • newInstance

      public static CompilationTestHelper newInstance(Class<? extends BugChecker> checker, Class<?> clazz)
      Returns a new CompilationTestHelper.
      Parameters:
      checker - the BugChecker to test
      clazz - the class to use to locate file resources
    • addSourceLines

      @CanIgnoreReturnValue public CompilationTestHelper addSourceLines(String path, String... lines)
      Adds a source file to the test compilation, from the string content of the file.

      The diagnostics expected from compiling the file are inferred from the file contents. For each line of the test file that contains the bug marker pattern "// BUG: Diagnostic contains: foo", we expect to see a diagnostic on that line containing "foo". For each line of the test file that does not contain the bug marker pattern, we expect no diagnostic to be generated. You can also use "// BUG: Diagnostic matches: X" in tandem with expectErrorMessage("X", "foo") to allow you to programmatically construct the error message.

      Parameters:
      path - a path for the source file
      lines - the content of the source file
    • addSourceFile

      @CanIgnoreReturnValue public CompilationTestHelper addSourceFile(String path)
      Adds a source file to the test compilation, from an existing resource file.

      See addSourceLines(java.lang.String, java.lang.String...) for how expected diagnostics should be specified.

      For most uses, addSourceLines(java.lang.String, java.lang.String...) is preferred. Using separate source files to denote positive/negative examples tends to bloat individual tests. Prefer writing smaller tests using addSourceLines(java.lang.String, java.lang.String...) which test a single behaviour in isolation.

      Parameters:
      path - the path to the source file
    • withClasspath

      @CanIgnoreReturnValue public CompilationTestHelper withClasspath(Class<?>... classes)
      Sets the classpath for the test compilation, overriding the default of using the runtime classpath of the test execution. This is useful to verify correct behavior when the classpath is incomplete.
      Parameters:
      classes - the class(es) to use as the classpath
    • addModules

      @CanIgnoreReturnValue public CompilationTestHelper addModules(String... modules)
    • setArgs

      Sets custom command-line arguments for the compilation. These will be appended to the default compilation arguments.
    • setArgs

      Sets custom command-line arguments for the compilation. These will be appended to the default compilation arguments.
    • expectNoDiagnostics

      @CanIgnoreReturnValue public CompilationTestHelper expectNoDiagnostics()
      Tells the compilation helper to expect that no diagnostics will be generated, even if the source file contains bug markers. Useful for testing that a check is actually disabled when the proper command-line argument is passed.
    • matchAllDiagnostics

      @CanIgnoreReturnValue public CompilationTestHelper matchAllDiagnostics()
      By default, the compilation helper will only inspect diagnostics generated by the check being tested. This behaviour can be disabled to test the interaction between Error Prone checks and javac diagnostics.
    • expectResult

      @CanIgnoreReturnValue public CompilationTestHelper expectResult(com.sun.tools.javac.main.Main.Result result)
      Tells the compilation helper to expect a specific result from the compilation, e.g. success or failure.
    • expectErrorMessage

      @CanIgnoreReturnValue public CompilationTestHelper expectErrorMessage(String key, Predicate<? super String> matcher)
      Expects an error message matching matcher at the line below a comment matching the key. For example, given the source
         // BUG: Diagnostic matches: X
         a = b + c;
       
      ... you can use expectErrorMessage("X", Predicates.containsPattern("Can't add b to c"));

      Error message keys that don't match any diagnostics will cause test to fail.

    • doTest

      public void doTest()
      Performs a compilation and checks that the diagnostics and result match the expectations.