Cómo mostrar datos en pruebas de Go: secretos de t.Log() y t.Logf() en 2025

Introducción: La pregunta eterna "¿Y cómo muestro algo en una prueba?"

Estás escribiendo una prueba en Go. La lógica es compleja, los datos están enredados, y necesitas desesperadamente ver qué está pasando dentro. Automáticamente escribes fmt.Println("valor =", x), ejecutas la prueba... y ves silencio. Sin salida. ¿Te suena?

Esta pregunta es una de las más populares en Stack Overflow entre desarrolladores Go principiantes (¡y no tan principiantes!). Parece que no hay nada más simple que mostrar una cadena. Pero en el mundo de las pruebas de Go, hay sus propias reglas y un conjunto de herramientas adecuadas. En este artículo, analizaremos todas las formas de mostrar salida en las pruebas, organizaremos las mejores prácticas de 2025 y mostraremos cómo no meter la pata. ¡Allá vamos!

¿Por qué fmt.Println se calla? (Y cuándo finalmente habla)

Vamos al grano. Cuando ejecutas pruebas con el comando go test (sin banderas), la salida estándar (stdout) se suprime. El ejecutor de pruebas de Go considera que si la prueba pasó correctamente, el usuario no necesita ver toneladas de información de depuración. Esto se hace por limpieza y automatización — imagina si cada prueba mostrara 10 líneas de registro en cada ejecución de CI/CD.

Sin embargo, hay dos excepciones en las que fmt.Println sí aparecerá en pantalla:

\n
• La bandera -v (verbose): go test -v. Este modo activa la salida detallada de todas las pruebas. Verás mensajes de fmt.Println y otras funciones.
\n
• La prueba falló: Si la prueba terminó con un error (se llamó a t.Error o t.Fatal), entonces la salida de fmt.Println de esa prueba se mostrará. Esto es muy útil para la depuración.
\n

Pero depender de fmt.Println es de mala educación. Para las pruebas en Go existe una herramienta especial, más correcta y potente.

El rey de la fiesta: t.Log() y t.Logf()

El objeto testing.T (que se pasa a cada prueba) tiene métodos integrados para el registro. Apréndetelos como el "Padre Nuestro": t.Log() y t.Logf().

package main\n\nimport (\n    "testing"\n)\n\nfunc TestSum(t *testing.T) {\n    result := 2 + 2\n    // Registro simple\n    t.Log("Iniciando prueba de suma")\n    t.Log("Resultado del cálculo:", result)\n\n    // Registro con formato (como fmt.Printf)\n    t.Logf("La suma de 2 y 2 es %d. ¡Prueba superada!", result)\n\n    if result != 4 {\n        t.Errorf("Esperábamos 4, obtuvimos %d", result)\n    }\n}

Ejecuta esta prueba con la bandera -v:

go test -v -run TestSum

Y verás mensajes bonitos y estructurados directamente en la salida de la prueba.

¿Por qué t.Log es mejor que fmt.Println?

\n
• Contexto: Los mensajes de t.Log se vinculan automáticamente a la prueba específica. En la salida con -v, ves qué prueba imprimió qué.
\n
• Controlabilidad: La salida de t.Log solo se muestra con -v o cuando la prueba falla. Esto significa que tus registros no saturan la consola en una ejecución normal.
\n
• Seguridad: A diferencia de fmt.Fprintf(os.Stderr, ...), t.Log funciona correctamente con pruebas paralelas (t.Parallel) y no causa condiciones de carrera.
\n

El lado oscuro de la fuerza: t.Error() y t.Fatal() como herramienta de salida

Muchos principiantes usan t.Error() solo para detener la prueba en caso de error. Pero en realidad es una excelente (¡y correcta!) forma de mostrar información de diagnóstico importante, especialmente cuando la prueba falla.

El secreto es que el mensaje pasado a t.Error() o t.Fatal() siempre se mostrará, incluso sin la bandera -v. Esto los hace ideales para mostrar información crí