Java tests for Kotlin files. Links in Java docs are not resolved

[alisevych]

Description

Generated Java tests for Kotlin files.
Kotlin code is addressed correctly from Java code.
But links in Java docs are not resolved.

To Reproduce

1. Install the latest UnitTestBot plugin build from main in IntelliJ Idea 2022.2.3 (latest)
2. Set Java as the language to generate tests in
3. Create a project with Kotlin support
4. Create a package in src/main/kotlin sources root
5. Add the following code to a Kotlin file:

package ort.utbot.examples.functions

fun foo(name: String, number: Int = 42, toUpperCase: Boolean = false) =
    (if (toUpperCase) name.uppercase() else name) + number

6. Generate tests for the file
7. Render Java docs and check the links

Expected behavior

Links in Java docs are supposed to lead to the used code.

Actual behavior

Links in Java docs are not resolved.

Visual proofs (screenshots, logs, images)

    /**
     * @utbot.classUnderTest {@link DefaultArgumentsKt}
     * @utbot.methodUnderTest {@link DefaultArgumentsKt#foo(String, int, boolean)}
     */
    @Test
    @DisplayName("foo: arg_0 has special characters, number < 0, toUpperCase = true")
    public void testFooWithBlankString() {
        String actual = DefaultArgumentsKt.foo("\n\t\r", -1, true);

        String expected = "\n\t\r-1";
        assertEquals(expected, actual);
    }

Environment

Windows 10 Pro
IntelliJ IDEA 2022.2.3
Gradle project with JDK 11

Additional context

Not reproducing in IDEA 2022.1.4 (links are resolved):

[amandelpie]

We never tested summaries for the Kotlin, probably it should be generated with disabled summarization to avoid bugs.

As I know KDocs (docstring format for Kotlin) has some differences for formatting and tags.

Also paths to the Kotlin classes forms in the different manner.

But I agree, that it should be or fixed or disabled for KDoc generation.

[amandelpie]

It looks like the implementation requires the two things:

• decision that we need this functionality (probably not)
• implement the own logic of KDocs because it's not the same like JavaDocs in the case of tags