Kotlin: java.lang.NoSuchMethodError en las testings

¿Es posible usar las funciones del package Kotlin y las properties del package en diferentes fonts? Cuando bash hacerlo, NoSuchMethodError .


Ejemplo

Tengo el proyecto Gradle con el código de Kotlin y dos fonts en él, main y test . En main , tengo el siguiente código en uno de los files:

 package ru.ifmo.ctddev.igushkin.dkvs ... public val payloadSplitter: String = " ### " 

En la test trato de acceder a payloadSplitter con el siguiente código:

 package ru.ifmo.ctddev.igushkin.dkvs ... public class MessageTests { ... test fun testParsing() { ... checkParseAndToString("p1b 345 ${payloadSplitter} set abc") } ... } 

Y exactamente en la primera línea donde se accede a payloadSplitter , en time de ejecución me sale

 java.lang.NoSuchMethodError: ru.ifmo.ctddev.igushkin.dkvs.DkvsPackage.getPayloadSplitter()Ljava/lang/String; 

Otras variables y funciones globales también son inaccesibles en la test con el mismo error.


El equipo de UPD Kotlin explicó el problema y anunció la solución aquí .

Para las properties y methods fuera de las classs, Kotlin crea una class java denominada package $ {packagename} con las properties y los methods implementados como methods y variables estáticos. Con múltiples sets de origen, la class Java se creará dos veces, una para cada set de origen. Su problema es que la "class de package" del set de orígenes de testing oculta la class comstackda en el set de orígenes principal.

Como se menciona en los comentarios anteriores, evite tener properties o methods de nivel superior en el set de origen de testing para evitar que el comstackdor de Kotlin cree esta class de package en el directory de salida de testing.

Además de lo sugerido anteriormente, encontré otra solución alternativa: si necesita funciones o properties a nivel de package en la test simplemente mueva las testings a un package diferente, por ejemplo, en las fonts de testing:

  package ru.ifmo.ctddev.igushkin.dkvs.tests 

y luego hacer

  import ru.ifmo.ctddev.igushkin.dkvs.* 

que es todo desde tu package principal. Esto hará que Kotlin complique genere dos classs de packages no conflictivas, por lo tanto, ambos pueden tener miembros globales.