El test runner de Storybook es la herramienta que te permite verificar si escribiste bien tus historias antes de avanzar con pruebas más complejas. Si trabajas con componentes en Storybook y quieres asegurar que cada historia cumple con el formato correcto, este flujo te ahorra horas de depuración manual.

¿Qué es el test runner de Storybook y para qué sirve?

El test runner es un comando que revisa si tus historias están escritas correctamente. No prueba lógica de negocio ni interacciones todavía, solo valida que la estructura de cada historia siga el formato esperado por Storybook.

La idea es simple: tú escribes historias para tus componentes y este corredor de pruebas te confirma que las escribiste bien. Si algo falla, te lo dice de inmediato con un mensaje que apunta al formato.

¿Qué hace exactamente el test runner? Ejecuta automáticamente cada historia de tu proyecto y verifica que esté bien formada. Si una historia tiene errores de sintaxis o estructura, el comando falla y te muestra dónde está el problema.

¿Cómo instalar y configurar el test runner paso a paso?

La configuración arranca desde la documentación oficial de Storybook, que encuentras en la caja de recursos. Desde ahí copias el comando de instalación y lo pegas en tu terminal.

Estos son los pasos concretos:

1. Abre la terminal en tu editor de código y pega el comando de instalación que aparece en la documentación oficial.
2. Espera a que termine la instalación de las dependencias.
3. Ve a tu archivo package.json y copia el script que la documentación indica para correr los tests.
4. Guarda los cambios en package.json.

Con eso ya tienes lista la configuración base. Lo siguiente es ejecutar el proyecto y los tests al mismo tiempo.

¿Por qué necesitas dos terminales abiertas?

Porque el test runner necesita que Storybook esté corriendo para poder revisar las historias. Una terminal mantiene viva la aplicación, la otra ejecuta las pruebas.

En la primera terminal corres npm run storybook y esperas a que el navegador se abra mostrando que Storybook está activo. En la segunda terminal corres npm run test-storybook y ahí es donde ves los resultados.

¿Cómo interpretar los resultados del test runner?

Cuando todo está bien escrito, el comando te confirma que las historias pasaron la validación. En el ejemplo de la clase, dos historias (la del componente de botón y la de la card) salieron aprobadas sin problemas [03:30].

La parte interesante viene cuando algo falla. Y aquí va una verdad incómoda del desarrollo: es la primera vez que uno se siente feliz de que algo falle, porque eso confirma que las pruebas realmente están haciendo su trabajo [04:00].

¿Qué significa cuando el test runner habla de formato? Significa que la historia no está escrita siguiendo la estructura que Storybook espera. El error de formato apunta directamente a problemas en la sintaxis o en la definición de la historia.

¿Cómo provocar un fallo a propósito para validar que funciona?

Una buena práctica es modificar una historia existente para forzar un error y comprobar que el test runner lo detecte. En la clase, se borra parte del contenido de la historia del botón y se vuelve a correr el comando [04:15].

El resultado es el esperado: el test falla y el mensaje menciona el formato como causa. Esa señal te confirma dos cosas:

• Tu test runner está configurado correctamente.
• La historia que modificaste ya no cumple con la estructura válida.

A partir de ahí, restauras el código y vuelves a correr el comando para confirmar que todo regresa al verde.

¿Qué viene después del test runner en el flujo de testing?

Este corredor de pruebas es solo el primer paso dentro del módulo de testing en Storybook. Una vez que confirmas que tus historias están bien escritas, el siguiente nivel son las pruebas de interacción, donde ya simulas clics, entradas de teclado y comportamientos reales del usuario sobre tus componentes.

Piénsalo como una pirámide: primero validas que la base (la escritura de historias) esté sólida, y después construyes encima pruebas más sofisticadas que revisan cómo se comporta el componente cuando alguien lo usa.

Cuéntame en los comentarios cómo te fue corriendo tu primer test runner. ¿Tus historias pasaron a la primera o tuviste que corregir algún error de formato?