Agrupación de Pruebas con Etiquetas

[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 →

A veces no quieres ejecutar todas las pruebas, y Kotest proporciona etiquetas para determinar qué pruebas se ejecutan en tiempo de ejecución. Las etiquetas son objetos que heredan de io.kotest.core.Tag.

Por ejemplo, para agrupar pruebas por sistema operativo podrías definir estas etiquetas:

object Linux : Tag()
object Windows: Tag()

Alternativamente, las etiquetas pueden definirse usando la clase NamedTag. Al usar esta clase, sigue estas reglas:

• Una etiqueta no puede ser nula o estar vacía.

• Una etiqueta no puede contener espacios en blanco.

• Una etiqueta no puede contener caracteres de control ISO.

• Una etiqueta no puede contener ninguno de estos caracteres:

  • !: signo de exclamación
  • (: paréntesis izquierdo
  • ): paréntesis derecho
  • &: ampersand
  • |: barra vertical

Por ejemplo:

val tag = NamedTag("Linux")

Etiquetado de Pruebas

Los casos de prueba pueden etiquetarse usando la función config:

import io.kotest.specs.StringSpec

class MyTest : StringSpec() {
  init {
    "should run on Windows".config(tags = setOf(Windows)) {
      // ...
    }

    "should run on Linux".config(tags = setOf(Linux)) {
      // ...
    }

    "should run on Windows and Linux".config(tags = setOf(Windows, Linux)) {
      // ...
    }
  }
}

Ejecución con Etiquetas

Al invocar el ejecutor de pruebas con la propiedad de sistema kotest.tags, controlas qué pruebas se ejecutan. La expresión debe ser una operación booleana simple usando operadores: &, |, !, con paréntesis para agrupación.

Por ejemplo: Tag1 & (Tag2 | Tag3)

Proporciona los nombres simples de los objetos etiqueta (sin paquete) al ejecutar las pruebas. ¡Presta atención a las mayúsculas y minúsculas! Si dos objetos etiqueta tienen el mismo nombre simple (en distintos espacios de nombres), se consideran la misma etiqueta.

Ejemplo: Para ejecutar solo pruebas etiquetadas con Linux, pero no con Database, invocarías Gradle así:

gradle test -Dkotest.tags="Linux & !Database"

Las etiquetas también pueden incluirse/excluirse en tiempo de ejecución (por ejemplo, en configuraciones de proyecto) mediante RuntimeTagExtension:

RuntimeTagExpressionExtension.expression = "Linux & !Database"

Operadores de Expresiones de Etiquetas

Operadores (en orden descendente de precedencia)

Operator	Description	Example
!	not	!macos
&	and	linux & integration
|	or	windows | microservice

Etiquetado de Todas las Pruebas

Puedes añadir una etiqueta a todas las pruebas de una spec usando la función tags en la propia spec. Por ejemplo:

class MyTestClass : FunSpec({

  tags(Linux, Mysql)

  test("my test") { } // automatically marked with the above tags
})

precaución

Al etiquetar pruebas así, la clase spec aún deberá instanciarse para examinar las etiquetas de cada prueba, ya que la prueba misma puede definir etiquetas adicionales.

nota

Si no hay pruebas raíz activas en tiempo de ejecución, los callbacks beforeSpec y afterSpec no se invocarán.

Etiquetado de una Spec

Hay dos anotaciones que puedes añadir a una clase spec: @Tags y @RequiresTag, que aceptan uno o más nombres de etiqueta como argumentos.

La primera anotación (@Tags) se aplica a todas las pruebas de la clase, pero solo evitará que se instancie la spec si podemos garantizar que no se ejecutaría ninguna prueba (por excluirse explícitamente una etiqueta).

Considera este ejemplo:

@Tags("Linux")
class MyTestClass : FunSpec({

  tags(UnitTest)

  beforeSpec { println("Before") }

  test("A").config(tags = setOf(Mysql)) {}
  test("B").config(tags = setOf(Postgres)) {}
  test("C") {}
})

Runtime Tags	Spec Created	Callbacks	Outcome
kotest.tags=Linux	yes	yes	A, B, C are executed because all tests inherit the Linux tag from the annotation
kotest.tags=Linux & Mysql	yes	yes	A is executed only because all tests have the Linux tag, but only A has the Mysql tag
kotest.tags=!Linux	no	no	No tests are executed, and the MyTestClass is not instantiated because we can exclude it based on the tags annotation
kotest.tags=!UnitTest	yes	no	No tests are executed because all tests inherit UnitTest from the tags function. MyTestClass is instantiated in order to retrieve the tags defined in the class. The beforeSpec callback is not executed because there are no active tests.
kotest.tags=Mysql	yes	yes	A is executed only, because that is the only test marked with Mysql
kotest.tags=!Mysql	yes	yes	B, C are executed only, because A is excluded by being marked with Mysql
kotest.tags=Linux & !Mysql	yes	yes	B, C are executed only, because all tests inherit Linux from the annotation, but A is excluded by the Mysql tag

La segunda anotación (@RequiresTag) solo verifica que estén presentes todas las etiquetas referenciadas y, si no, omite la spec.

Por ejemplo, esta spec se omitiría y no se instanciaría a menos que las etiquetas Linux y Mysql estuvieran especificadas en tiempo de ejecución.

@RequiresTag("Linux", "Mysql")
class MyTestClass : FunSpec()

nota

Al usar estas anotaciones, pasa el nombre de cadena de la etiqueta, no la etiqueta misma. Esto se debe a que las anotaciones de Kotlin solo permiten argumentos "primitivos".

Herencia de etiquetas

Por defecto, la anotación @Tags solo se considerará en la Spec inmediata donde se aplicó. Sin embargo, una Spec también puede heredar etiquetas de superclases y superinterfaces. Para habilitar esto, active tagInheritance = true en su configuración de proyecto

Gradle

Necesitas prestar especial atención a tu configuración de Gradle

Para utilizar propiedades del sistema (-Dx=y), debes configurar Gradle para propagarlas a los ejecutores de pruebas, y añadir una configuración adicional en tus tests:

Groovy:

test {
    //... Other configurations ...
    systemProperties = System.properties
}

Kotlin DSL de Gradle:

val test by tasks.getting(Test::class) {
    // ... Other configurations ...
    systemProperties = System.getProperties().associate { it.key.toString() to it.value }
}

Esto garantizará que la propiedad del sistema sea leída correctamente por la JVM.