Configuración a nivel de proyecto

[Traducción Beta No Oficial]

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Kotest es flexible y ofrece múltiples formas de configurar pruebas, como definir el orden de ejecución dentro de un spec o cómo se instancian las clases de prueba. En ocasiones, querrás establecer esto a nivel global mediante la configuración a nivel de proyecto.

La configuración a nivel de proyecto se implementa creando un objeto o clase que herede de AbstractProjectConfig.

Cualquier configuración establecida a nivel de Spec o directamente en una prueba anulará la configuración especificada a nivel de proyecto.

Entre las opciones disponibles en KotestProjectConfig destacan: paralelismo de pruebas, fallo de specs con tests ignorados, AssertSoftly global, y listeners o extensiones reutilizables.

Detección en tiempo de ejecución

En tiempo de ejecución, Kotest escaneará clases que extiendan AbstractProjectConfig y las instanciará, aplicando los valores de configuración definidos en ellas.

Puedes crear múltiples clases de configuración en distintos módulos. Todas las presentes en el classpath actual serán detectadas y sus configuraciones se fusionarán. Esto permite centralizar configuraciones comunes en módulos raíz. En conflictos, se elegirá un valor arbitrariamente, por lo que se desaconseja añadir configuraciones contradictorias.

En proyectos grandes, puedes desactivar el escaneo automático si genera costes de inicio significativos. Para ello, define la propiedad del sistema o variable de entorno kotest.framework.classpath.scanning.config.disable como true.

Tras desactivar el escaneo automático, puedes especificar un nombre de clase conocido que Kotest instanciará reflectivamente. Usa la propiedad del sistema o variable de entorno kotest.framework.config.fqn.

Por ejemplo, establecer:

kotest.framework.classpath.scanning.config.disable=true
kotest.framework.config.fqn=com.wibble.KotestConfig

Desactivará el escaneo en tiempo de ejecución y buscará la clase com.wibble.KotestConfig. Esta clase debe seguir heredando de AbstractProjectConfig.

consejo

Otra configuración relacionada es kotest.framework.classpath.scanning.autoscan.disable, que también puede establecerse a false para mayor velocidad. Con el escaneo automático desactivado, Kotest no escaneará el classpath en busca de extensiones anotadas con @AutoScan.

precaución

Las propiedades del sistema establecidas en tu archivo gradle no serán recogidas por el plugin de intellij si lo tienes instalado. En su lugar, especifica las propiedades dentro de un archivo kotest.properties. Detalles completos aquí.

Paralelismo

Puedes configurar Kotest para ejecutar especificaciones en paralelo y aprovechar CPUs modernos con múltiples núcleos estableciendo el nivel de paralelismo (por defecto es 1). Las pruebas dentro de una especificación siempre se ejecutan secuencialmente.

Para ello, sobreescribe parallelism en tu configuración y asígnalo a un valor mayor que 1. Este número representa la cantidad de especificaciones que se ejecutan concurrentemente. Por ejemplo:

object KotestProjectConfig : AbstractProjectConfig() {
    override val parallelism = 3
}

Un método alternativo es usar la propiedad de sistema kotest.framework.parallelism, que siempre tendrá prioridad sobre el valor configurado aquí si está definida.

Algunas pruebas pueden no comportarse correctamente en paralelo, por lo que puedes excluir especificaciones individuales y forzar su ejecución en aislamiento usando la anotación @DoNotParallelize.

nota

Esta funcionalidad solo está disponible en el target JVM.

Modo de aserción

Puedes configurar Kotest para que falle la compilación o muestre advertencias en stderr si se ejecuta una prueba que no utiliza aserciones de Kotest.

Para esto, establece assertionMode a AssertionMode.Error o AssertionMode.Warn en tu configuración. Un método alternativo es usar la propiedad de sistema kotest.framework.assertion.mode, que siempre tendrá prioridad si está definida.

object KotestProjectConfig : AbstractProjectConfig() {
    override val assertionMode = AssertionMode.Error
}

precaución

El modo de aserción solo funciona con aserciones de Kotest, no con otras librerías. Esto se debe a que las aserciones deben ser compatibles explícitamente con este modo cuando está activado.

Global Assert Softly

Assert Softly es muy útil para agrupar errores en un único fallo. Para activarlo automáticamente en cada prueba, puedes configurarlo aquí. Alternativamente, establece la propiedad de sistema kotest.framework.assertion.globalassertsoftly a true, que siempre tendrá prioridad si está definida.

object KotestProjectConfig : AbstractProjectConfig() {
    override val globalAssertSoftly = true
}

Gestión de nombres de prueba duplicados

De forma predeterminada, Kotest renombrará una prueba si tiene el mismo nombre que otra prueba en el mismo ámbito. Añadirá _1, _2, etc. al nombre de la prueba. Esto es útil para pruebas generadas automáticamente.

Puedes cambiar este comportamiento globalmente configurando duplicateTestNameMode como DuplicateTestNameMode.Error o DuplicateTestNameMode.Warn.

Error hará que falle el conjunto de pruebas con un nombre repetido, mientras que warn lo renombrará pero mostrará una advertencia.

Fallar en pruebas ignoradas

Puedes considerar una prueba ignorada como un fallo. Para activar esta funcionalidad, establece failOnIgnoredTests a true en tu configuración de proyecto. Por ejemplo:

object KotestProjectConfig : AbstractProjectConfig() {
    override val failOnIgnoredTests = true
}

Orden

Kotest admite ordenar tanto las especificaciones (specs) como las pruebas de forma independiente.

Orden de pruebas

Al ejecutar múltiples pruebas desde una Spec, existe un orden determinado para su ejecución.

Por defecto se usa un orden secuencial (el orden en que las pruebas están definidas en la spec), pero esto puede cambiarse. Para opciones disponibles consulta orden de pruebas.

Ordenamiento de Especificaciones (Specs)

Por defecto, el orden de las clases Spec no está definido. Esto suele ser suficiente cuando no tenemos preferencia, pero si necesitamos controlar el orden de ejecución de las specs, podemos usar orden de especificaciones.

Nomenclatura de pruebas

Los nombres de las pruebas se pueden ajustar de varias formas.

Mayúsculas y minúsculas

El uso de mayúsculas/minúsculas en los nombres de prueba se puede controlar cambiando el valor de testNameCase.

Por defecto, el valor es TestNameCase.AsIs, que no realiza ningún cambio.

Al establecerlo en TestNameCase.Lowercase, el nombre de la prueba aparecerá en minúsculas en los resultados.

Si usas una spec que añade prefijos a los nombres de prueba (como WordSpec o BehaviorSpec), los valores TestNameCase.Sentence y TestNameCase.InitialLowercase pueden ser útiles.

Etiquetas en nombres de prueba

Otra opción es testNameAppendTags, que cuando se establece en true incluirá cualquier etiqueta aplicable en el nombre de la prueba. Por ejemplo, si una prueba foo se define en una spec con las etiquetas linux y spark, el nombre de prueba se ajustaría a foo [linux, spark].

Esta configuración también puede establecerse mediante la propiedad del sistema o variable de entorno kotest.framework.testname.append.tags con valor true.

Espacios en blanco en nombres de prueba

Si defines nombres de prueba en varias líneas, removeTestNameWhitespace puede ser útil. Considera este ejemplo:

"""this is
   my test case""" {
  // test here
}

Entonces el nombre aparecerá como this is my test case. Al activar removeTestNameWhitespace, se normalizará a this is my test case.

Una alternativa es establecer la propiedad del sistema kotest.framework.testname.multiline como true, que siempre (si está definida) tiene prioridad sobre este valor.

object KotestProjectConfig : AbstractProjectConfig() {
    override val testNameRemoveWhitespace = true
}