Add KtLintAssertThat for asserting unit tests in a fluent style

[paul-dingemans]

Description

AssertJ style assertion for verifying KtLint rules. This class is intended to be used as follows:

Create an assertThat assertion for a specific rule or set of rules. If possible define it at the class level

val someRuleAssertThat = SomeRule().assertThat()
val multipleRulesAssertThat = listOf(SomeRule1(), SomeRule2).assertThat()

The created assertThat can than be used in test method similar to the normal assertThat:

@Test
fun `Some test`() {
    val code = .... // Original code to be formatted
    val formattedCode = .... // The code as it should be formatted
    someRuleAssertThat(code)
        .hasLintErrors(
            LintError(1, 1, "some-rule-id", "some-error-description")
        ).isFormattedAs(formattedCode)
}

The ktlintAssertThat provides access to methods like:

• withEditorConfigOverride
• asKotlinScript
• hasNoLintErrors
• hasNoLintErrorsBeforeFormatting
• hasLintErrors
• hasLintErrorsBeforeFormatting
• isFormattedAs
• hasNoLintErrorsAfterFormatting
• hasLintErrorsAfterFormatting

All tests of the IndentationRule, with exception of the tests using the spec file, have been rewritten with ktlintAssertThat. Other classes will be rewritten as well but I would like to get some feedback on the idea.

Checklist

• PR description added
• tests are added
• CHANGELOG.md is updated

In case of adding a new rule:

• README.md is updated
• Rule has been applied on Ktlint itself and violations are fixed

[romtsn]

Sry, I don't have much time to review this in full, but if you're going to expose this to consumers (looking at public class KtlintAssertThat - you are), we should also make the assertj dependency api instead of implementation, cause people might not use assertj in their custom rulesets.

[paul-dingemans]

Sry, I don't have much time to review this in full, but if you're going to expose this to consumers (looking at public class KtlintAssertThat - you are), we should also make the assertj dependency api instead of implementation, cause people might not use assertj in their custom rulesets.

Done. Learned a again a bit about gradle ;-)
The dependencies for my test rule (the one about indenting raw string literals), now looks like:

    compileOnly "com.pinterest.ktlint:ktlint-core:$ktlintVersion"

    testImplementation 'org.junit.jupiter:junit-jupiter:5.8.2'
    testImplementation "com.pinterest.ktlint:ktlint-test:$ktlintVersion"

Should junit also be exposed as API dependency?

[romtsn]

Should junit also be exposed as API dependency?

No, not really, because you are not exposing any junit types as API (in case of assertj - KtLintAssertThat extends AbastractAssert, which will be part of the public API, hence we need to expose it)

[paul-dingemans]

Should junit also be exposed as API dependency?

No, not really, because you are not exposing any junit types as API (in case of assertj - KtLintAssertThat extends AbastractAssert, which will be part of the public API, hence we need to expose it)

Tnx for explaining.

[paul-dingemans]

This PR consists of adding a new KtLintAssertThat API plus a massive rewrite of all tests using the new test API. Also all spec files have been replaced with normal unit tests. Due to shere volume of change, I do not expect anybody to be able/willing to review this. So, I will just merge it when builds succeeds.

Note that during this endeavour, I encountered multiple potential bug and issues. I have left TODO remarks in Test classes and added Tests marked with @disabled where applicable and created #1456 as reminder to fix them.