Configuración de Vitest para pruebas unitarias en Next.js

Contenido del curso

Web App con FastAPI + Docker

Frontend con Next.js y Cursor IDE

iOS con Swift + Cursor IDE

Android + Cursor IDE

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:007:07

Configuración de Vitest para pruebas unitarias en Next.js

Curso de Cursor AI Code Editor

Clase 14 de 25

Clase 14 / 25

Recursos

Configurar pruebas unitarias con Vitest en un proyecto Next.js se vuelve mucho más rápido cuando usas un agente de IA bien guiado. Aquí aprenderás a elegir la herramienta correcta, instalarla con documentación oficial y dejar reglas listas para automatizar la creación de tests en cualquier componente.

Cómo elegir entre Vitest y Jest para un proyecto Next.js

Antes de instalar cualquier librería, conviene preguntarle al agente qué se ajusta mejor a tu stack. En lugar de usar el modo agente, abrimos un chat en modo pregunta y le pasamos como contexto el package.json [00:18].

El prompt es directo: analiza la estructura del proyecto y dime qué es mejor usar para pruebas unitarias, Vitest o Jest. Con esa información, el agente revisa las dependencias y propone la mejor opción según tu caso.

En este escenario, el proyecto corre con Next 15, TypeScript y React 19, sin herramientas de testing configuradas. La recomendación fue Vitest por cuatro razones concretas:

Compatibilidad nativa con Next.
Mejor rendimiento en la ejecución de pruebas.
Configuración más simple que Jest.
Soporte directo para TypeScript.

¿Vitest o Jest para Next.js 15? Vitest es la opción recomendada por su compatibilidad con Next, mejor rendimiento, configuración simple y soporte nativo de TypeScript.

Por qué pasarle la documentación oficial al agente

Una cosa es que el agente te diga cómo instalar y otra distinta es que use la fuente correcta. Y aquí viene lo interesante: en lugar de seguir los pasos que el chat improvisó, abrimos la documentación oficial de Next.js con Vitest y copiamos la URL [01:30].

Luego abrimos un nuevo chat, esta vez en modo agente, y le pedimos: configura Vitest para realizar mis pruebas unitarias, instala las dependencias necesarias y usa esta documentación. La idea es que no dependa de su preentrenamiento, sino que lea la guía actualizada.

El agente pide permiso para instalar las dependencias, entre ellas:

vitest.
@testing-library/react.
@testing-library/dom.
@testing-library/jest-dom.

¿Por qué darle la URL de la documentación al agente? Para que use información actualizada en lugar de su preentrenamiento, evitando configuraciones obsoletas o incompatibles con tu versión de Next.

Cómo crear la primera prueba unitaria de un componente

Una vez instaladas las dependencias, llega el momento de generar el primer test. Dentro del componente de curso creamos una carpeta llamada test y le compartimos al agente el componente junto con la ruta de destino [03:05].

El prompt es claro: crea los test unitarios de este componente y guárdalos en la siguiente carpeta. Arrastras la carpeta al chat y envías.

El agente lee el componente, escribe las pruebas y al ejecutar run test el resultado fue: un archivo pasado y tres pruebas exitosas. Todo verde.

En este caso, el archivo se guardó dentro de una carpeta en source y no en la ruta indicada. La solución es manual y rápida:

Aceptar los cambios generados.
Mover el archivo a la carpeta correcta.
Permitir que el agente actualice los imports.
Borrar la carpeta anterior y volver a correr los tests.

Los tests se reiniciaron y volvieron a pasar sin problemas.

Cómo definir reglas reutilizables para futuras pruebas

El objetivo final no es crear un solo test, sino dejar instrucciones para que el agente replique la misma calidad en cualquier componente. Aquí entran las cursor rules.

Abres un nuevo chat, compartes el componente y pides: genera las reglas generales de mis pruebas unitarias, deben funcionar para cualquier componente [04:30]. El agente produce un archivo llamado unit-test-guideline que documenta:

La estructura con bloques describe.
El uso de mocks para dependencias externas.
El render con @testing-library/react.
El manejo de props en los componentes.
Un ejemplo concreto de la estructura esperada.

Ese ejemplo es la pieza clave. Cuando el agente tiene un patrón de referencia, puede generar tests consistentes para los siguientes componentes sin que tengas que repetir instrucciones.

Ahora te toca a ti: configura Vitest en tu proyecto, crea tu primera prueba unitaria y deja tus cursor rules listas. Cuéntame en los comentarios qué componente vas a testear primero.

Daniel Flores

Hace un año

🧪 ¿Por qué elegir Vitest para pruebas en Next.js?

Para proyectos con Next.js + TypeScript + React, Vitest es ideal por:

✅ Alta compatibilidad con Next.js 🚀 Rendimiento superior frente a Jest en ejecución 🧠 Fácil configuración inicial 🔐 Integración fluida con TypeScript

📦 La elección puede automatizarse tras analizar archivos como package.json y la estructura del proyecto.

)

🤖 Generación automática de pruebas con asistente (como Cursor)

Para pruebas unitarias rápidas:

📁 Coloca los tests cerca del componente (src/components/Button/Button.test.tsx)
💬 Comparte el archivo del componente en el chat del asistente
🧠 Cursor generará test con:
- Mocks necesarios
- Render del componente
- Pruebas con getByText, toBeInTheDocument, etc.

🔧 Ajusta rutas de importación si cambiaste carpetas o estructura.

📐 Establecer reglas generales de pruebas

Crea tu propia Unit Test Guidelines con:

📌 Uso de describe() y it() bien estructurados 🧱 Props base estandarizadas para cada componente 📄 Componentes comunes a testear: botones, formularios, modales 📁 Estructura recomendada del árbol de carpetas de pruebas 💬 Instrucciones claras para agentes/autogeneradores

Esto asegura que todas las pruebas tengan una base coherente, incluso cuando se generan automáticamente.

✅ Ventajas finales de usar Vitest

⚡️ Rápido y eficiente
🧬 Compatible con JSX y TypeScript
🤖 Se puede combinar con agentes como Cursor para pruebas autogeneradas
🔍 Compatible con herramientas modernas como Playwright para tests e2e

Rolando Perez

Hace un año

Nuevo paradigma en vez de TDD (Test Driven Development) ahora es RDD (Rule Driven Development).

Web App con FastAPI + Docker

Vibe coding con Cursor en dos semanas

Stack tecnológico para plataforma educativa online

Configuración de contexto y reglas en Cursor para FastAPI

Setup de FastAPI con Cursor paso a paso

Ejecución autónoma de setup con Cursor

Cursor dentro de un contenedor Docker

Migraciones y modelos ORM con Cursor y Alembic

Creación de servicios y endpoints en FastAPI con Docker

Pruebas unitarias en FastAPI con PyTest

Frontend con Next.js y Cursor IDE

Cursor Agent para front-end sin configuración

Creación y configuración de Cursor Rules para proyectos Next.js

Mejora visual de landing pages con imágenes y tokens CSS

Configuración de estilos globales SCSS y páginas dinámicas en Next.js

Configuración de Vitest para pruebas unitarias en Next.js

Página completa con un solo prompt en Cursor

E2E testing con Playwright MCP en Cursor

iOS con Swift + Cursor IDE

Configuración de Cursor con Xcode para desarrollo iOS nativo

Configura reglas y contexto en Cursor

Genera UI en SwiftUI con prompts en Cursor

Cursor genera capas data y domain en iOS

Conexión de view models con capas domain y data

Android + Cursor IDE

Setup de Cursor para apps Android con Kotlin

Cursor genera una app Android desde cero

Corrección de errores de dependencias con Cursor en Android Studio

Cursor en equipo: entrega frontend en un día

Configuración de Vitest para pruebas unitarias en Next.js

Progreso del curso

Web App con FastAPI + Docker

Frontend con Next.js y Cursor IDE

iOS con Swift + Cursor IDE

Android + Cursor IDE

Recursos

Recursos