Lanzamiento 4.2

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

El equipo de Kotest se complace en anunciar el lanzamiento de Kotest 4.2.0. Esta versión menor de características continúa el excelente trabajo incluido en la versión 4.1.0 (¡que de por sí fue casi tan grande como el lanzamiento 4.0.0!).

En esta publicación cubriremos algunas de las características y cambios más destacados, pero para la lista completa consulta el registro de cambios.

Cambios en módulos

En primer lugar, la dependencia kotest-runner-console ya no es necesaria para el plugin de IntelliJ, por lo que ha dejado de existir. Puedes eliminarla completamente de tu build si la estabas utilizando.

En segundo lugar, la dependencia kotest-core ha pasado a llamarse kotest-framework-engine.

• Si estás utilizando tests JVM, debes seguir usando la dependencia kotest-runner-junit5-jvm como antes, sin cambios necesarios.

• Si dependías explícitamente del módulo core (para tests JS), ahora puedes añadir kotest-framework-engine a tu sourceset commonMain o kotest-framework-engine-js a tu sourceset jsMain.

Finalmente, esta versión de Kotest es totalmente compatible con Kotlin 1.4.

Mejoras multiplataforma

La biblioteca de aserciones principal ahora está publicada para ios, watchos y tvos. Esto amplía la lista de plataformas soportadas a:

• linuxX64, mingwX64, macosX64, tvosX64, tvosArm64, watchosX86, watchosArm64, iosX64, iosArm64, iosArm32

Matchers para Kotlinx Date/Time

Se ha creado un nuevo módulo de aserciones llamado kotest-assertions-kotlinx-time que contiene matchers para la nueva biblioteca Kotlinx Datetime. Dado que la biblioteca de datetime tiene estado incubating, este módulo de aserciones podría requerir cambios disruptivos en el futuro si la API de fecha/hora lo exige.

Este módulo de aserciones es multiplataforma y está disponible para JVM, JS, Linux, Mac y Windows.

Un ejemplo de aserción es verificar que una fecha-hora tiene una hora específica.

val date = LocalDateTime(2019, 2, 15, 12, 10, 0, 0)
date.shouldHaveHour(12)

Para la lista completa de matchers, consulta el código fuente.

Múltiples configuraciones de proyecto

Kotest permite personalizar planes de prueba extendiendo la clase AbstractProjectConfig y ubicándola en tu classpath. A partir de 4.2.0, puedes crear más de una configuración y todas serán detectadas y fusionadas. Esto es ideal si deseas tener una configuración compartida para todas tus pruebas en un módulo raíz, y luego personalizar con detalles más específicos por módulo.

En caso de conflictos, se elegirá un valor arbitrariamente, por lo que no se recomienda añadir configuraciones contradictorias en diferentes archivos.

Callbacks extendidos

Kotest siempre ha tenido callbacks beforeTest/afterTest que se ejecutan antes/después de cualquier 'ámbito de prueba'. Sin embargo, a veces necesitas ejecutar código de setup/teardown solo antes de ámbitos de prueba hoja (llamados tests en Kotest) o ámbitos de prueba rama (llamados contenedores en Kotest).

Por ello, en 4.2.0 hemos introducido beforeEach, afterEach, beforeContainer y afterContainer. Las funciones xxEach se invocan solo para ámbitos de prueba hoja. Las funciones xxContainer se invocan solo para ámbitos de prueba rama.

Esta distinción solo es relevante para los estilos de prueba que admiten ámbitos anidados.

Por ejemplo:

class CallbacksTest : DescribeSpec({

   beforeEach {
      println("Test: " + it.displayName)
   }

   beforeContainer {
      println("Container: " + it.displayName)
   }

   beforeTest {
      println("All: " + it.displayName)
   }

   describe("I am a container scope") {
      it("And I am a test scope") { }
   }
})

La salida que obtendrías sería:

Container: I am a container scope
All: I am a container scope

Test: And I am a test scope
All: And I am a test scope

Ordenamiento de Especificaciones (Specs)

Anteriormente, Kotest permitía que el orden de ejecución de las Specs fuera aleatorio, por orden de descubrimiento (por defecto) o lexicográfico. Ahora, se ha añadido soporte para un enfoque basado en anotaciones. Al seleccionar esta opción y anotar tus Specs con @Order(int), puedes especificar cualquier orden que desees, ejecutándose primero las specs con valores enteros más bajos.

Cualquier spec sin la anotación @Order se considera "última". Las specs con valores iguales se ejecutarán de forma arbitraria.

Expresiones de Etiquetas (Tags)

Las pruebas y Specs pueden etiquetarse con objetos Tag, y durante la ejecución se pueden habilitar o deshabilitar pruebas especificando qué etiquetas usar. Anteriormente, esto solo permitía incluir o excluir etiquetas sin funcionalidades avanzadas.

Ahora, puedes especificar expresiones booleanas completas usando la propiedad del sistema kotest.tags, por ejemplo:

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

Las expresiones pueden anidarse usando paréntesis y ser arbitrariamente complejas. Para detalles completos, consulta Etiquetas.

Nota: Las propiedades existentes kotest.tags.include y kotest.tags.exclude siguen soportadas, pero la nueva funcionalidad las reemplaza.

Anulaciones de Timeout a Nivel de Spec

Siempre ha sido posible agregar un timeout a nivel global o configurarlo por prueba individual:

 test("my test").config(timeout = 20.seconds) { }

Pero antes no era posible anularlo a nivel de spec para todas las pruebas de esa spec. Ahora sí puedes.

class TimeoutTest : DescribeSpec({

   timeout = 1000

   describe("I will timeout in 1000 millis") {
      it("And so will I") { }
      it("But I'm a little faster").config(timeout = 500.milliseconds) { }
   }

})

Nota: Puedes aplicar un timeout a nivel de spec y luego anularlo por prueba individual, como se muestra en el ejemplo anterior. La misma funcionalidad existe para timeouts de invocación.

Exhaustividad Específica en forAll / checkAll

En pruebas de propiedades, si usas solo generadores exhaustive, los métodos forAll/checkAll ahora garantizan que el número de iteraciones coincida con las combinaciones posibles y que todas se ejecuten.

Como ejemplo artificial, considera esto:

 val context = checkAll(
    Exhaustive.ints(0..5),
    Exhaustive.ints(0..5),
    Exhaustive.ints(0..5)
 ) { ... }

Aquí, el número de iteraciones es 6 6 6 = 216, y cada combinación de tuplas (0-5, 0-5, 0-5) se ejecutará. La primera será (0, 0, 0) y la última (5, 5, 5), cubriendo todas las combinaciones intermedias.

Contratos Genéricos en Matchers

When using shouldBeInstanceOf<T> or shouldBeTypeOf<T>, the assertions can now use generic contracts to smart case down to generic instances.

Por ejemplo, considera el siguiente ejemplo donde se nos proporciona un Any. Tras invocar shouldBeTypeOf con un tipo genérico, el tipo se convierte inteligentemente si la aserción pasa.

val list: Any = arrayListOf(1, 2, 3)
list.shouldBeTypeOf<ArrayList<Int>>()
list[0] shouldBe 1 // can only work with a smart case

Actualizaciones del Plugin Kotest

El Plugin Intellij de Kotest se publica con un calendario independiente, pero aquí hay cambios destacados desde Kotest 4.1.0:

• No se necesitan dependencias adicionales: el plugin incluye todas las bibliotecas requeridas.

• Los nuevos callbacks extendidos son reconocidos en la ventana de herramientas de Kotest.

• Ahora se soporta ejecutar pruebas individuales en AnnotationSpec.

• Compilaciones separadas para Android Studio/Intellij 2019 para resolver incompatibilidades menores.

• Se añadió una inspección para evitar usar modo foco en pruebas anidadas.

• Proveedor de uso implícito para configuraciones de proyecto basadas en objetos.

Informe XML de JUnit mejorado

El informe XML JUnit (lo que JUnit denomina informe XML heredado porque existía antes de JUnit5) no tiene concepto de pruebas anidadas. Por lo tanto, si usas un estilo de especificación que admite pruebas anidadas, el generador de informes de Gradle solo usará el nombre de la prueba hoja. Esto puede resultar confuso si esperas la ruta completa de la prueba para tener contexto.

En la versión 4.2.0, Kotest incluye su propia implementación de este informe XML con opciones para: a) incluir la ruta completa de la prueba y/o b) ignorar completamente las pruebas padre.

Ejemplo de uso desde la configuración del proyecto:

class ProjectConfig : AbstractProjectConfig() {

   override fun listeners(): List<Listener> = listOf(
     JunitXmlReporter(
        includeContainers = true, // write out status for all tests
        useTestPathAsName = true // use the full test path (ie, includes parent test names)
     )
   )
}

Advertencia del Spring Listener

Advertencia sobre el listener de Spring

Si usas la compatibilidad con Spring y utilizas una clase final, Kotest mostrará una advertencia:

Puedes deshabilitar esta advertencia configurando la propiedad del sistema kotest.listener.spring.ignore.warning a true.

Agradecimientos

Un enorme agradecimiento a todos los que han contribuido a esta versión.

Alberto Ballano, Ali Albaali, amollberg, Ashish Kumar Joy, Christian Stoenescu, Cleidiano Oliveira ,Daniel Asztalos, fauscik, Juanjo Aguililla, Justin, Leonardo Colman, Matthew Mikolay, Neenad Ingole, Shane Lathrop, sksamuel, Timothy Lusk