test: Added unit tests for LSP-based code folding and the code block provider (issue 673)

[SCWells72]

The title is pretty self-explanatory. The only thing worth pointing out explicitly is that I've added some utility methods to the common base test case class for deriving the before/after index of specific substrings in test file bodies to avoid having to hard-code them.

[SCWells72]

Tests are run in dumb mode so if we want to test this, we need to allow that, at least for test execution.

[SCWells72]

Same thing here...allow dumb mode during test execution.

[SCWells72]

Each of these test scenarios include the initial caret offset, the expected caret offset when move-to-block-start occurs, and the expected caret offset when move-to-block-end occurs. As you can see, I've added some utility methods to the common base test case class that allow us to derive those indices dynamically rather than hard-coding them, (hopefully) resulting in much more flexible tests if/when test file bodies change.

[SCWells72]

Using the same utility methods here to derive the expected text ranges dynamically.

[SCWells72]

No new tests were added here, but I extracted common constants for repeated strings for consistency with what I did in the new tests added in this PR.

[SCWells72]

This is the important step required to trigger folding behavior in the file. You'll see it in both of the new base test case classes.

[SCWells72]

Here are the utility methods referenced earlier.

[SCWells72]

Again, force population of the folding model in test mode.

[angelozerr]

It is just my opinion, but I find using constant is not easy to read, because you need to jump to the constant to know the value.

But if you prefer , keep like this.

[angelozerr]

Instead of expecting some offset, I think it will more readable to expect a string which have the same content of the editor but with some annotations like <fold1> ends with </fold1>

It follows the same idea with the <caret> that you can use in a test (see for instance completion test, where I use <caret]>instead of using the offset number see, for instance

lsp4ij/src/test/java/com/redhat/devtools/lsp4ij/features/completion/TypeScriptCompletionTest.java

Line 55 in 254cf2e

assertApplyCompletionItem(0, "''.charAt<caret>");

[angelozerr]

Here a sample with folding ranges:

public void testFoldingRanges() {
        assertFoldingRanges(
                "demo.ts",
                """
                export class Demo {
                    demo() {
                        console.log('demo');
                    }
                }
                """,
                // language=json
                """
                        [
                          {
                            "startLine": 0,
                            "endLine": 3
                          },
                          {
                            "startLine": 1,
                            "endLine": 2
                          }
                        ]
                        """,
                """
                <fold1>export class Demo {
                    demo() {
                        console.log('demo');
                    }
                }</fold1>
                """
        );
    }
}

[SCWells72]

I've changed the tests to provide a balance between readability and maintainability. Tokens are now used, but directly in the test file source, and they're both extracted for offset information and stripped from the file body for the actual PsiFile creation. That way you're only maintaining one version of the file body with tokens representing key locations.

Let me know if that doesn't address your concerns.

[angelozerr]

Impressive!