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 las pruebas dentro de una especificación o cómo se crean las clases de prueba. En ocasiones, es útil establecer estas configuraciones globalmente mediante la configuración a nivel de proyecto.

Puedes utilizar la configuración a nivel de proyecto creando un objeto o clase que extienda de AbstractProjectConfig. Durante la ejecución, Kotest escaneará clases que extiendan esta clase abstracta, las instanciará y leerá cualquier configuración definida en ellas.

Puedes crear múltiples clases de configuración en diferentes módulos, y todas las presentes en el classpath actual serán detectadas y fusionadas. Esto permite centralizar configuraciones comunes en un módulo raíz. En caso de conflictos, se seleccionará un valor arbitrariamente, por lo que no se recomienda añadir configuraciones contradictorias en diferentes clases.

nota

Si tu proyecto define más de una configuración de proyecto, estas se fusionarán, pero la resolución de valores conflictivos no está especificada. Se recomienda evitar definir los mismos ajustes en configuraciones separadas.

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 de configuración disponibles en KotestProjectConfig se incluyen: paralelismo de pruebas, fallo en especificaciones con pruebas ignoradas, AssertSoftly global, y listeners o extensiones reutilizables.

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
}

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 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.

Orden de especificaciones

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 ordenación de specs.

Formato de nombres de pruebas

El formato de mayúsculas/minúsculas en los nombres de prueba se controla mediante testNameCase. Por defecto es TestNameCase.AsIs, que no realiza cambios.

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

Si usas specs que añaden prefijos a los nombres (como WordSpec o BehaviorSpec), los valores TestNameCase.Sentence y TestNameCase.InitialLowercase pueden ser útiles.

Espacios en nombres de pruebas

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
}