Los tests automatizados o pruebas son una parte fundamental de todo lenguaje de programación y framework.
Hoy vamos a ver cómo escribir tests para probar nuestro código en Go. Será un ejemplo bastante sencillo pero ilustrará perfectamente cómo realizar pruebas a nuestro código.
Lo que veremos será:
go test
Recuerda que antes de esto debes instalar y configurar Go. Si estás en Windows mira este post, y si estás en Linux Ubuntu mira este otro.
Go ya incluye un paquete para hacer las pruebas: testing, y lo importamos así:
import "testing"
No es tan robusto como otros que conocemos, pero es simple y cumple con lo necesario.
En algún post sobre una comparativa entre Rust y Go leí algo muy cierto:
En un buen lenguaje (como C), para agregar más funcionalidades se escribe más código, no se agregan más características al lenguaje.
Es decir, si quisiéramos una librería más robusta la escribiríamos nosotros mismos con lo que el lenguaje proporciona, todo lo contrario a que los programadores de Go agregaran nuevas características que tendríamos que aprender con cada nueva versión.
Dejemos un momento los tests y centrémonos en un poco de código.
Para ilustrar esto de la forma más básica vamos a hacer una función que suma dos números. Si la llamamos con 1
y 2
, debería devolver 3
, ¿cierto?
El código queda así:
package main
/*
Una simple función que suma (y que vamos a probar más adelante)
en Go
@author parzibyte
*/
import "fmt"
func main() {
resultado := sumar(1, 2)
fmt.Printf("El resultado de la suma es: %d", resultado)
}
func sumar(a int, b int) int {
return a + b
}
Muy simple, pero en nuestro código verdadero puede que tengamos situaciones más complejas, funciones que regresen otros datos, consumo de bases de datos, etcétera.
Y siempre deberían regresar los mismos resultados si se llaman con los mismos argumentos, así evitamos los típicos “Ahhhh cierto, olvidé que al modificar X cosa se iba a romper mi función”
Pero bueno, ya creamos nuestra función y va de maravilla. Ahora veamos cómo probarlo; es decir, cómo probarlo (verificar su comportamiento) del verbo en inglés test, no del verbo try.
El archivo de hace un momento se llama main.go
, los tests en Go deben ir en un archivo llamado como sea pero que termine en _test.go
.
Por ejemplo, si tuvieras un archivo llamado ClientesController.go
entonces el que lo prueba debería llamarse ClientesController_test.go
.
En este caso le pondré main_test.go
y queda así:
package main
/*
Probar la función Sumar que existe en main.go
@author parzibyte
*/// Importa el paquete:
import "testing"
// Escribe TestXXXX en donde XXXX es el nombre de la función original
func TestSumar(t *testing.T) { // Recibir struct de tipo testing.T
resultado := sumar(1, 2)
resultadoEsperado := 3
if resultado != resultadoEsperado {
t.Errorf("Error en %s. Se esperaba %d pero el resultado fue %d", t.Name(), resultadoEsperado, resultado)
}
// Y si no, o sea, si todo va bien, no hacemos nada
}
Todas las funciones deben comenzar con Test, para este ejemplo recibimos un apuntador a testing.T
; hacemos una simple comparación (que la suma de 1 y 2 debería ser 3) y si no es así entonces llamamos a t.Errorf
que imprime un error formateado.
Aquí viene la magia, ahora ve la carpeta en donde está el código y ejecuta:
go test
Go (bueno, la herramienta) va a buscar aquellos archivos terminados en _test.go y ejecutarlos. Si quieres que se muestren más mensajes pasa la opción -v
go test -v
En mi caso se ve así:
Presta atención a la consola. Dice PASS, significa que todo fue bien.
Es importante mencionar que los archivos de test no van a ser incluidos cuando el código sea compilado.
Ahora supongamos que tu código ha crecido bastante pero afortunadamente has programando varios tests, un compañero nuevo toca tu código y modifica la suma para que regrese a - b
.
Cuando se ejecuten las pruebas veremos qué es lo que pasa:
Ohhh sí, los tests han fallado y ahora sabes que algo no anda bien. De esta manera vas, arreglas el código y vuelves a probar.
Te aseguro que con esto vas a eliminar más de la mitad de errores cuando tu app esté en producción.
No olvides escribir suficientes tests expresivos (que indiquen qué se esperaba, qué se dio y en dónde fue), rígidos y variados.
La recomendación de todo test es que primero se deben escribir los tests, y luego las funciones. Es decir, en la primera vez se falla al propósito, luego se escribe la función y se acierta.
En este caso lo hice al revés (y no pasa nada) pero recuerda lo que dicen:
Haz lo que digo, no lo que hago
Al final queda en ti, pero en serio, deberías seguir esa recomendación.
No te limites aescribir una sola prueba, escribe las suficientes y las más rígidas; recuerda que los programadores libramos una batalla contra los usuarios que se empeñan en buscar fallas en nuestro software, y hasta el momento ellos van ganando.
Para agregar más pruebas escribe más funciones, también puedes agregar más archivos.
Finalmente te invito a ver la documentación del paquete, y a leer más sobre Go en mi blog.
Hoy te voy a presentar un creador de credenciales que acabo de programar y que…
Ya te enseñé cómo convertir una aplicación web de Vue 3 en una PWA. Al…
En este artículo voy a documentar la arquitectura que yo utilizo al trabajar con WebAssembly…
En un artículo anterior te enseñé a crear un PWA. Al final, cualquier aplicación que…
Al usar Comlink para trabajar con los workers usando JavaScript me han aparecido algunos errores…
En este artículo te voy a enseñar cómo usar un "top level await" esperando a…
Esta web usa cookies.