Vitest 5.1, publicado el 2 de noviembre, incorpora vitest run --since-last-run: ejecuta solo los tests cuyos archivos cambiaron desde su propia última ejecución, más cualquier test que falló la vez anterior y todavía no pasa. Es experimental, no necesita Git y la primera ejecución es completa: el ahorro empieza en la segunda.
La versión también trae una revisión interactiva de snapshots y un flag --last-failed. Los vemos más abajo, pero lo principal es la selección de tests, porque cambia el comando que ejecutas decenas de veces al día.
¿Qué es Vitest y en qué se diferencia de Jest?
Vitest es el test runner nativo de Vite: usa una API compatible con la de Jest (describe, it, expect, con vi en lugar de jest para mocks y timers), es open source con licencia MIT y, si ya usas Vite, reutiliza tu configuración y tu pipeline de transformación en lugar de mantener uno aparte. Por eso la búsqueda vitest vs jest suele terminar en lo mismo: migrar es, en buena parte, cambiar imports.
Con 5.1, Vitest suma la revisión de snapshots uno por uno (algo que Jest ya ofrecía en su modo interactivo) y una selección de tests que compara contra tu última ejecución en lugar de contra Git.
¿Cómo ejecutar solo los tests afectados por un cambio en Vitest?
Usa --since-last-run. En la primera ejecución, Vitest corre todos los tests y registra los archivos que cargó cada uno, incluidos imports dinámicos, mocks, archivos de setup y archivos de snapshot. En cada ejecución posterior, un test vuelve a correr si:
- uno de sus archivos registrados es más reciente que su última ejecución, o fue eliminado;
- todavía no tiene registro (los archivos de test nuevos siempre se ejecutan);
- falló la última vez y no ha pasado desde entonces, aunque la corrección esté en un archivo fuera de su registro.
Cada ejecución actualiza los registros de los tests que corrió, así que la referencia sigue tus ejecuciones, no un commit.
vitest run --since-last-run
Los registros se guardan en la caché de Vitest. Para reiniciarlos:
vitest run --clearCache
El siguiente --since-last-run después de eso vuelve a ser una ejecución completa.
Por debajo, la función se apoya en otras dos piezas experimentales, experimental.recordDependencies y un nuevo proveedor de VCS llamado mtime; por eso todo el conjunto lleva la etiqueta de experimental. Al momento de publicar esta nota, la guía de esta función (en inglés, affected tests) solo estaba en el sitio de documentación de la próxima versión (main.vitest.dev), no en la documentación estable.
¿--changed o --since-last-run: cuál conviene usar?
Responden preguntas distintas: --changed compara contra una referencia de Git; --since-last-run compara contra tu última ejecución de tests.
vitest run --changed # cambios sin commitear, staged y unstaged
vitest run --changed HEAD~1 # el último commit más los cambios sin commitear
vitest run --changed origin/main # todo lo de esta rama
La limitación de --changed: necesita un repositorio Git y, una vez que un cambio queda commiteado, deja de contar como cambiado, aunque nunca hayas ejecutado los tests contra él. A --since-last-run los commits le dan igual.
La recomendación de la propia documentación de Vitest:
| Objetivo | Usa |
|---|---|
| Una rama, antes de abrir o actualizar un pull request | --changed origin/main |
| Los commits que estás por hacer push | --changed <upstream> |
| Cambios sin commitear en un repo Git | cualquiera de los dos |
| Cambios desde tu última ejecución de tests, commiteados o no | --since-last-run |
| Un directorio sin Git, o con un historial que no controlas | --since-last-run |
Regla práctica: --changed para una referencia compartida (CI, pull requests) y --since-last-run para tu ciclo personal.
¿Qué tests puede pasar por alto --since-last-run?
La documentación menciona dos puntos ciegos:
- Archivos que ningún test cargó la última vez. Un
.envnuevo o un archivo nuevo en__mocks__no está en el registro de nadie, así que modificarlo no dispara nada. - Fechas de modificación en el pasado. Un checkout o un archivo comprimido descomprimido pueden dejar archivos con mtimes antiguos, y el flag compara mtimes.
La solución es la misma para ambos: ejecuta la suite completa (vitest run) una vez antes de terminar.
¿Cómo usar --since-last-run con agentes de IA?
Los agentes hacen commits a mitad de la tarea, trabajan en contenedores y worktrees temporales, y lanzan un proceso nuevo por cada comando: justo los casos en los que --changed pierde el hilo. La documentación de Vitest sugiere añadir esto al AGENTS.md de tu proyecto:
- After a change, run `vitest run --since-last-run` to test only what the change affects.
- Before you finish, run `vitest run` once for the whole suite.
La segunda línea es la que cubre los puntos ciegos de la sección anterior.
¿Cómo volver a ejecutar solo los tests fallidos en Vitest?
Con el nuevo --last-failed, que vuelve a ejecutar únicamente los tests que fallaron en la última ejecución (los lee de la caché de resultados) y se combina con filtros:
vitest run --last-failed -t login
Si un archivo falló fuera de un test (en beforeAll o durante la recolección), se ejecuta el archivo completo.
¿Cómo revisar y actualizar snapshots uno por uno en Vitest?
En modo watch, la tecla u sigue actualizando todos los snapshots fallidos de una vez. La nueva revisión interactiva, inspirada en el comando review de Insta, los recorre uno a uno: pulsa i para abrirla, a para aceptar el snapshot nuevo y r para conservar el anterior. Al terminar el último, Vitest escribe los snapshots aceptados y vuelve a ejecutar los archivos afectados. Cubre snapshots inline, archivos .snap, file snapshots y snapshots ARIA en Browser Mode.
¿Qué más cambia en Vitest 5.1?
- Trace View en Browser Mode pasa a estable y viene activado por defecto (
browser.traceView.mode, con'failure-only'como valor por defecto);browser.traceView.enabledqueda obsoleto. - Vitest coverage con
istanbul: el proveedor deja Babel y pasa a Oxc a través de Rolldown; el equipo reporta una instrumentación de 5 a 10 veces más rápida (cifra del propio proyecto). - Puerto de Browser Mode: el puerto por defecto pasa de
63315a23315. Configuraapi.portsi algo depende del anterior.
¿Cómo empezar con --since-last-run?
Actualiza a Vitest 5.1 y ejecuta el flag dos veces: la primera registra, la segunda selecciona.
vitest run --since-last-run # ejecución completa, crea el registro
# edita un archivo
vitest run --since-last-run # solo lo que tocó esa edición
¿Y tú? ¿Cuánto tarda hoy tu suite completa y en qué momento la ejecutas?
- Ejecuto siempre la suite completa
- Uso el modo watch o --changed
- Filtro a mano por archivo o por nombre
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: Code-review-graph: Tu Agente Revisa Solo los 15 Archivos que Importan, no los 27.000