[abashev]

Adding a formatter test meant a Java method with two text blocks and a formatter around them, or an .input/.output pair in testdata/. Now it can be one file in open-java-format/src/test/resources/test-cases/. In order:

1. the suite, with one test moved into it;
2. every before-and-after test of FormatterTest and JBangDirectivesTest that needs no settings;
3. reading the cases byte for byte;
4. the testdata/ pairs that need no settings, each as an LF, a CRLF and a CR case;
5. a fix that keeps two pairs other modules read;
6. the pairs whose input has no final line break, which the second dashes can now follow directly;
7. 13 pairs of StringWrapperIntegrationTest, lengthened to cross 120 columns;
8. a fix in the string wrapper that their move turned up, with the other five pairs; it changes what the formatter outputs, see below;
9. five more testdata/ pairs, with copies for the modules that read two of them.

The case file

A header, six or more dashes that end a line, the code before formatting, a second run of such dashes and the code expected after it. The header may be empty, and then the file starts with the dashes. There are no settings yet, so the header takes blank lines and # comments, which explain the case; any other line fails the case.

# Why this case exists.
----------
class A{}
----------
class A {}

The file is read as it is. The before block runs from the line after the first dashes up to the second ones. On a line of their own they leave it its last line break; at the end of its last line they leave it none, for an input that does not end in one:

----------
class MyClass {
    private void myFile() {}
}----------
class MyClass {
    private void myFile() {}
}

The after block runs from the line after the second dashes to the end of the file, with a final line break or without. Line breaks stay \n, \r\n or \r, whichever the file has, and .gitattributes keeps git from converting them in *.case files. A line of code that ends in six or more dashes would be a separator itself, so it cannot be part of a case; none is, and such a file fails with three separators found.

The suite

FormatterCasesTest finds the .case files anywhere under test-cases/ on the test classpath and runs one test per file, named by its path without the extension. The before block through formatSourceAndFixImports in the OJF style must give the after block, and a second run must change nothing. A failure first names the line of the case file where the output departs from the after block, with both versions of that line, and then shows both texts:

[test-cases/nonNlsMarkersStayOnTheLineOfTheirLiteral.case, first run, line 25
  expected:                 "third one"); //$NON-NLS-6$
  actual:                   "third one"); //$NON-NLS-5$]

The output has to match the after block byte for byte. A file without exactly two lines of dashes fails its own test, and a missing or empty folder fails the suite rather than passing with no tests.

The tests moved into cases

The first commit moves nonNlsMarkersStayOnTheLineOfTheirLiteral. The second moves every test that formatted a string and compared the result with another string in the code, one file per test and one per row of a parameterized test: 23 tests of FormatterTest and all 40 of JBangDirectivesTest, which goes; its cases are test-cases/jbang/<method>-<row>.case. A one-off generator read the strings from the test sources through javac's tree, so none was retyped, and the comments of the tests became the # headers of their cases.

The 19 of them that formatted in the GOOGLE style now run in OJF, the one style the formatter has. Their inputs are unchanged and each expected output is the OJF one; for all but two it equals the old one with every indent doubled, so the test checks the same thing. The two that wrap at the line limit were checked by hand:

• wrapMarkdownDocstringComment fitted in 120 columns, so its sentence got three more words and wraps again.
• wrapMarkdownDocstringRunKeepsTheSlashPrefix now wraps right before @Deprecated. On JDK 25 a formatter from before the fix for Code won't compile after Markdown Javadoc is formatted palantir/palantir-java-format#1803 drops the /// there and makes it an annotation, so the case still catches the bug. It was skipped below JDK 23 and now runs on every JDK; every case has the same output on JDK 21, 25 and 27.

wrapLineComment stays in FormatterTest: its output, in GOOGLE as in OJF, changes on a second run, which the cases check. That is a formatter bug, to be fixed separately. It and the seven other tests that stay in FormatterTest but formatted in GOOGLE use an OJF formatter now; only wrapLineComment and blankLinesImportComment change their expected text.

The testdata pairs

FormatterIntegrationTest checked each pair four times: the formatted input against the output, then the output with LF, CR and CRLF line breaks against itself. 254 of the 256 pairs become three cases each, testdata/<name>-lf.case, -crlf.case and -cr.case, with those line breaks. A case formats its before block and has to give the after block, then formats that again and has to change nothing, so the CR and CRLF copies check a whole run with their line breaks, not only the output.

The 28 among them whose input does not end in a line break, JavaFileNoNewLine too, put the second dashes right after the input's last character. A case also runs the import pass, which FormatterIntegrationTest skipped, and for three pairs the after block differs from the old output: M loses the blank line between its two imports, Unformatted gets its imports sorted into one block, and ojf-issue-24-jbang-script gets a blank line between the comment after its last import and the annotated class. The cases of the other 251 pairs hold the pair byte for byte.

Other modules read two of the pairs and now keep their own copies: PalantirDeeplyNestedCalls.java of the benchmarks is a file instead of a link to palantir-deeply-nested-calls.input, and the IntelliJ plugin's PalantirJavaFormatFormattingServiceTest reads A.input and A.output from its own test resources.

Two pairs stay in testdata/: ModuleImport needs JDK 23, and the import pass of a case would remove the unused import of B21647014 before formatting, and one of the stray semicolons after it with it. FileBasedTests.VERSIONED_TESTS keeps only ModuleImport.

The string wrapper pairs

StringWrapperIntegrationTest reflowed strings at 40 columns, a setting a case does not have: a case wraps at 120, as the CLI does. Its 18 pairs become test-cases/stringwrapper/<n>-lf.case, -crlf.case and -cr.case, each with a # line on what it checks, and the test goes. The inputs keep their old shape and get longer, so that each case does at 120 columns what its pair did at 40: the sentence most of them share has the same two insertions everywhere, the runs of letters of 13 and 14 are three times as long, and 6, 7, 9, 10 and 16 cross 120 columns as they are. The releases from before the fixes behind 16 and the NON-NLS pair, 2.98.0.1 and 2.98.0.3, fail those cases. The outputs are the same on JDK 21, 25 and 27.

A fix in the string wrapper

Lengthened, pairs 1, 2, 5, 8 and 11 came out with the pieces of their string four columns in, where OJF continues a line eight columns in:

class T {
    String s = "one long incredibly unbroken sentence that went on through breakfast and lunch and dinner and long"
        + " into the night moving from topic to topic so that no-one sitting anywhere near the long dining table, not"
        + " even the host or the cook, had a chance to interrupt";
}

The wrapper laid the pieces out four columns in. Its second formatting pass moved them to eight, and when that pushed a piece past the limit, it reflowed the text again and left it unformatted. A plain reformat of such output moved the lines, while running the formatter again gave the same output, so neither the old test nor the second run of a case noticed; release 2.98.0.1 does the same. The reflow now takes the continuation indent from the formatter, four columns times the multiplier of its style, for the width of the lines after the first and for the column of their +:

class T {
    String s = "one long incredibly unbroken sentence that went on through breakfast and lunch and dinner and long"
            + " into the night moving from topic to topic so that no-one sitting anywhere near the long dining table,"
            + " not even the host or the cook, had a chance to interrupt";
}

Without the fix 21 of the 54 cases fail: those five pairs and 0 and 3, whose continuation line of exactly 120 columns now ends a word earlier, because the reflow fills a continuation line up to 119 columns. A plain reformat leaves the after block of every case as it is. Of the 15,747 files of the JDK 21 sources, 319 format differently: 292 whose old output a plain reformat changed, and 27 with a continuation line of exactly 120 columns.

Test counts on JDK 21

	before	after
FormatterTest	43	19
JBangDirectivesTest	40	–
StringWrapperIntegrationTest	72	–
FormatterIntegrationTest	1024	8
FormatterCasesTest	–	880
CaseFileTest	–	16
module	1658	1402

Every other class is unchanged. Each moved test of FormatterTest and JBangDirectivesTest is one case, and each moved pair is its three cases, where the integration tests counted four checks; that is why the module has fewer tests. 14 tests are skipped instead of 15, because the slash-prefix case runs below JDK 23 now. ./gradlew test --rerun passes in every module.

Next

The fix for the unstable comment wrap, with wrapLineComment moved into a case; the two pairs left in testdata/; and the other classes that still format in GOOGLE, with Formatter.create() defaulting to OJF.