Pistas

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

nota

Las pistas solo funcionan si usas la biblioteca de aserciones de Kotest

Una regla general es que una prueba fallida debería parecerse a un buen informe de error. En otras palabras, debería indicar qué salió mal y, idealmente, por qué ocurrió.

A veces, una aserción fallida contiene suficiente información en el mensaje de error para saber qué salió mal.

Por ejemplo:

username shouldBe "sksamuel"

Podría dar un error como:

expected: "sksamuel" but was: "sam@myemailaddress.com"

En este caso, parece que el sistema llena el campo de nombre de usuario con una dirección de correo.

Pero supongamos que tienes una prueba como esta:

user.name shouldNotBe null

Si esto fallara, simplemente obtendrías:

<null> should not equal <null>

Lo cual no es particularmente útil. Aquí es donde entra en juego withClue.

Los helpers withClue y asClue añaden contexto adicional a las aserciones para que los fallos sean autoexplicativos:

Por ejemplo, podemos usar withClue con un mensaje de texto

withClue("Name should be present") {
  user.name shouldNotBe null
}

Daría un error como este:

Name should be present
<null> should not equal <null>

El mensaje de error mejoró bastante, pero aún podría ser mejor. Por ejemplo, sería útil conocer el id del usuario para verificar la base de datos.

Podemos usar withClue para añadir el id del usuario al mensaje de error:

withClue({ "Name should be present (user_id=${user.id})" }) {
  user.name shouldNotBe null
}

También podemos usar la función de extensión asClue para convertir cualquier objeto en el mensaje de pista.

{ "Name should be present (user_id=${user.id})" }.asClue {
user.name shouldNotBe null
}

El mensaje se calculará solo si la prueba falla, por lo que es seguro usarlo con operaciones costosas.

consejo

Los fallos en pruebas incluyen: aserción fallida, nombre de prueba, pistas y traza de ejecución. Plantea su uso de modo que respondan tanto qué falló como por qué falló. Esto hará las pruebas más fáciles de mantener, especialmente al intentar entender la intención del autor.

consejo

Cada vez que veas un comentario sobre una aserción, considera usar asClue o withClue en su lugar. Los comentarios no son visibles en los fallos de pruebas (especialmente en CI), mientras que las pistas sí.

También puedes usar objetos de dominio como pistas:

data class HttpResponse(val status: Int, val body: String)

val response = HttpResponse(404, "the content")

response.asClue {
    it.status shouldBe 200
    it.body shouldBe "the content"
}

Mostraría:

HttpResponse(status=404, body=the content)
Expected :200
Actual   :404

nota

Kotest considera todas las pistas () -> Any? como lazy (evaluación perezosa): las computa y usa .toString() en el resultado en lugar de llamar a .toString() en la función misma. Normalmente esto es lo que necesitas, pero si un objeto pista implementa () -> Any? y prefieres usar clue.toString(), envuélvelo manualmente como { clue.toString() }.asClue { ... }.

Pistas anidadas

Las pistas pueden anidarse y todas serán visibles en los mensajes de aserciones fallidas:

{ "Verifying user_id=${user.name}" }.asClue {
  "email_confirmed should be false since we've just created the user".asClue {
    user.emailConfirmed shouldBe false
  }
  "login".asClue {
    user.login shouldBe "sksamuel"
  }
}

El fallo podría verse así:

Verifying user_id=42
email_confirmed should be false since we've just created the user
<true> should equal <false>