Escribir tu primer test puede parecer intimidante, pero la estructura es más sencilla de lo que imaginas. Entender cómo se organiza un archivo de pruebas y qué papel juegan las funciones principales de un test runner como Vitest te dará la base para garantizar que tu código funcione como esperas. Aquí se desglosan los fundamentos de la pirámide de testing y se escribe paso a paso un primer archivo de pruebas funcional.
¿Qué es la pirámide de testing y por qué importa?
La pirámide de testing organiza los tipos de pruebas según su alcance y cantidad [0:08]:
- Unit tests: prueban funciones o piezas muy específicas del código. Están en la base porque son las más numerosas y rápidas.
- Integration tests: verifican que varias unidades funcionen correctamente en conjunto.
- End-to-end tests: simulan el uso real de la aplicación, incluyendo bases de datos y APIs. Se ubican en la cima porque son más costosos de ejecutar.
Como mencionó Kent C. Dodds, creador de Testing Library: "entre más se asemejen tus tests a la manera en que tu software será usado, mayor confiabilidad vas a tener" [0:42]. Esta frase resume por qué el testing no es opcional, sino una práctica esencial para cualquier proyecto profesional.
¿Cómo se estructura un archivo de test con describe, it y expect?
Cada archivo de test sigue una estructura de tres capas que permite organizar las pruebas de forma clara [1:00]:
- describe: agrupa los casos de prueba relacionados. Recibe un nombre descriptivo y un callback donde se definen los tests.
- it: representa cada caso de prueba individual. También recibe una descripción y un callback.
- expect: contiene la aserción, es decir, la verificación de que el resultado obtenido coincide con el esperado.
Piensa en el expect como una condicional: si se cumple lo que esperas, el test pasa; si no, falla [2:42].
¿Por qué el archivo necesita la extensión .test?
Al crear un archivo de pruebas, es fundamental incluir la extensión .test.tsx [1:28]. Esta convención le indica al test runner —ya sea Vitest, Jest u otro— que ese archivo contiene pruebas y debe ejecutarse como tal. Sin esa extensión, el archivo será ignorado.
¿Cómo se escribe un primer test con una función suma?
El primer caso de prueba verifica que una función de suma opere correctamente [1:55]:
tsx
import { describe, it, expect } from 'vitest';
describe('Mi primer test', () => {
it('la suma de dos números', () => {
const suma = (a: number, b: number) => a + b;
const resultado = suma(2, 3);
expect(resultado).toBe(5);
});
});
El matcher toBe compara el valor obtenido con el esperado [2:55]. Si cambias el valor esperado a 6, el test fallará indicando que recibió 5 pero esperaba 6 [3:20]. Eso confirma que la aserción funciona correctamente.
Vitest ofrece múltiples matchers además de toBe, como toEqual, toBeTruthy o toContain, entre otros. Cada uno sirve para distintos tipos de comparaciones.
¿Cómo verificar que dos textos sean iguales?
El segundo caso de prueba compara dos cadenas de texto [3:42]:
tsx
it('dos textos iguales', () => {
const textoUno = 'Platzi conf';
const textoDos = 'Platzi';
expect(textoUno).toBe(textoDos);
});
Este test falla intencionalmente porque "Platzi conf" no es igual a "Platzi" [4:05]. Al corregir textoDos a "Platzi conf", ambos tests pasan exitosamente [4:22].
Este comportamiento confirma algo importante: un test que falla cuando debe fallar es tan valioso como uno que pasa. La confiabilidad del testing radica justamente en detectar discrepancias reales.
Ahora que conoces la estructura básica, el reto es crear nuevos casos de prueba: multiplicaciones, divisiones, comparaciones de arrays o textos. Comparte tus resultados y experimenta con distintos matchers para afianzar lo aprendido.
