Gutenberg adopta Vitest para sus pruebas JavaScript unitarias y de integración

El proyecto Gutenberg ha actualizado la tecnología utilizada en sus pruebas unitarias y de integración de JavaScript. A partir de ahora, este conjunto de pruebas utiliza Vitest, una decisión orientada a mejorar el trabajo con módulos JavaScript modernos y a facilitar las pruebas de componentes en navegadores reales.

El cambio también afecta a la forma en que se definen los entornos de ejecución. Según la información publicada por el equipo de WordPress Core, cada archivo de prueba puede seleccionar entre Node, jsdom o Browser Mode según las necesidades concretas del código que se está evaluando.

Vitest pasa a ser la base de las pruebas de Gutenberg

Las pruebas unitarias y de integración cumplen funciones diferentes, aunque ambas son importantes para mantener la calidad de un proyecto como Gutenberg. Las primeras se centran en unidades concretas de código, mientras que las segundas permiten comprobar cómo funcionan varios componentes cuando trabajan conjuntamente.

El uso de Vitest proporciona a estas pruebas un marco adaptado a los módulos JavaScript actuales. El resumen publicado por WordPress Core destaca, en particular, una mejor compatibilidad con los módulos modernos y con las pruebas de componentes ejecutadas en un navegador real.

Esto no significa que todas las pruebas se ejecuten de la misma manera. La configuración se ajusta al tipo de prueba que contiene cada archivo, con tres posibilidades principales: Node, jsdom y Browser Mode.

Tres entornos según las necesidades de cada prueba

Node

El entorno Node está pensado para las pruebas que no necesitan una representación del navegador. Puede resultar adecuado para comprobar lógica JavaScript que no depende de elementos visuales, del documento HTML o de APIs específicas del navegador.

jsdom

jsdom ofrece un entorno que simula determinadas capacidades del navegador dentro de JavaScript. Este tipo de configuración permite trabajar con pruebas que necesitan un documento o una estructura de interfaz, sin llegar a ejecutarse en un navegador real.

Browser Mode

Browser Mode permite realizar pruebas de componentes en un navegador real. Esta posibilidad es especialmente relevante cuando el comportamiento que se quiere comprobar depende de la ejecución efectiva en el navegador y no solo de una simulación.

La elección del entorno se realiza de acuerdo con lo que necesita cada prueba. El resultado es una organización más explícita: el archivo indica qué tipo de ejecución requiere en lugar de asumir que todas las pruebas deben utilizar un único entorno.

Las pruebas importan sus APIs de forma explícita

Otro cambio señalado por WordPress Core es que las pruebas importan de forma explícita las APIs de Vitest que utilizan. En la práctica, esto hace más visible la relación entre cada archivo de prueba y las funciones proporcionadas por el marco.

Para los equipos de desarrollo, esta decisión puede facilitar la lectura y el mantenimiento del código. Al revisar una prueba, resulta más sencillo identificar qué herramientas proceden de Vitest y cuáles forman parte de la lógica propia del proyecto. También establece una pauta clara para los nuevos archivos que se incorporen al código de Gutenberg.

La información disponible no detalla una lista completa de cambios internos ni ofrece cifras comparativas de rendimiento. Por tanto, el alcance confirmado de la actualización se encuentra en el marco de pruebas, la compatibilidad con módulos modernos, la selección de entornos y la ejecución de componentes en navegador real.

@wordpress/scripts 36.0.0 establece Vitest por defecto

La actualización también alcanza a @wordpress/scripts. La versión 36.0.0 convierte Vitest en el ejecutor predeterminado para test-unit-js.

Este detalle es importante para los proyectos que utilizan las herramientas de WordPress para ejecutar pruebas JavaScript. El comportamiento por defecto cambia, de modo que los equipos deben tener en cuenta que el flujo asociado a test-unit-js se apoya ahora en Vitest.

Sin embargo, el cambio no implica que todos los proyectos queden configurados automáticamente de la misma forma. La información publicada indica que cada proyecto debe instalar y configurar su propio ejecutor de pruebas. Por ello, la adopción de Vitest en Gutenberg no debe interpretarse como una configuración universal que elimine las decisiones técnicas de cada equipo.

Consecuencias prácticas para los desarrolladores

• Revisar la configuración: los proyectos que utilicen @wordpress/scripts deben comprobar cómo afecta la versión 36.0.0 a sus comandos de pruebas.
• Identificar el entorno adecuado: cada prueba debe ejecutarse en Node, jsdom o Browser Mode según las APIs y los componentes que necesite.
• Importar las APIs de forma explícita: los nuevos archivos de prueba deben seguir el modelo de importación directa de las funciones de Vitest.
• Separar las necesidades del proyecto: la configuración del ejecutor corresponde a cada proyecto, por lo que conviene revisar dependencias y ajustes antes de asumir que el cambio está completado.
• Valorar las pruebas en navegador real: los componentes cuyo comportamiento dependa del navegador pueden beneficiarse de la disponibilidad de Browser Mode.

Estas consecuencias son principalmente operativas. El cambio ofrece una base común para las pruebas de Gutenberg, pero exige que los equipos entiendan qué entorno corresponde a cada caso y mantengan su propia configuración.

Qué significa para usuarios y profesionales

Para los usuarios finales de Gutenberg, la adopción de Vitest es un cambio técnico interno. No introduce, según la información disponible, una función nueva visible directamente en el editor ni modifica por sí misma la experiencia de creación de contenidos.

Su importancia está relacionada con la forma en que se valida el código antes de llegar a los usuarios. Un sistema de pruebas que contempla módulos modernos y componentes ejecutados en un navegador real puede ayudar a los equipos a comprobar distintos comportamientos del editor con herramientas más adecuadas para cada escenario. Aun así, la fuente no presenta datos que permitan cuantificar una mejora concreta en estabilidad, velocidad o número de errores.

Para los profesionales que desarrollan bloques, extensiones o integraciones con WordPress, el anuncio sirve como referencia técnica. Conviene revisar las dependencias de pruebas, conocer los entornos disponibles y no asumir que una configuración heredada funcionará sin ajustes. La decisión de Gutenberg sitúa a Vitest como una pieza relevante del flujo de pruebas JavaScript del proyecto, mientras que la responsabilidad de instalar y configurar el ejecutor continúa en cada equipo.

---

Fuente: WordPress Core.