Dónde se ejecutan las pruebas

Por lo general, las pruebas automatizadas se pueden ejecutar ejecutando una secuencia de comandos manualmente o con un auxiliar de un framework de pruebas, a menudo llamado ejecutor de pruebas, para encontrar y ejecutar y pruebas. Sin embargo, es posible que no siempre quieras tener que ejecutar tus secuencias de comandos de forma manual. Hay varias formas de ejecutar las pruebas que pueden proporcionar comentarios y confianza en diferentes momentos del ciclo de vida del desarrollo.

Secuencia de comandos de requisito previo

Los proyectos web suelen tener un archivo de configuración (su archivo package.json), es decir, configurado por npm, pnpm, Bun o similares. Este archivo de configuración contiene tus las dependencias del proyecto y otra información, así como las secuencias de comandos auxiliares. Estos Las secuencias de comandos auxiliares pueden incluir la manera de compilar, ejecutar o probar tu proyecto.

Dentro de package.json, deberás agregar una secuencia de comandos llamada test que describa cómo ejecutar las pruebas. Esto es importante porque, cuando usas npm o una versión herramienta, la "prueba" “secuencia de comandos” tiene un significado especial. Esta secuencia de comandos puede apuntar a un único archivo que arroje una excepción. algo como node tests.js, pero te recomendamos que lo uses para apuntar a un ejecutor de pruebas establecido.

Si usas Vitest como ejecutor de pruebas, tu El archivo package.json se verá de la siguiente manera:

{
  "name": "example-project",
  "scripts": {
    "start": "node server.js",
    "test": "vitest --run"
  }
}

Si ejecutas npm test con este archivo, se ejecuta el conjunto de pruebas predeterminado de Vitest una vez. En Vitest, la opción predeterminada es encontrar todos los archivos que terminan con “.test.js” o similares y ejecutarlas. Según tu elegido, el comando puede ser un poco diferente.

Hemos elegido usar Vitest, un framework de prueba cada vez más popular, para ejemplos a lo largo de este curso. Puedes leer más sobre esta decisión en Vitest como ejecutor de pruebas. Sin embargo, es importante recordar que los frameworks y los ejecutores de prueba en todos los idiomas, tienden a tener una lengua vernácula común.

Invocación de prueba manual

Activar manualmente tus pruebas automatizadas (como usar npm test en el ejemplo anterior) puede resultarte práctico mientras trabajas activamente en una base de código. Escribir pruebas para una función mientras la desarrollas puede ayudarte a obtener una sentido de la forma en que debe funcionar la función, esto hace referencia al concepto de y el desarrollo basado en pruebas (TDD).

Los ejecutores de pruebas suelen tener un comando corto que puedes invocar para ejecutar todas tus pruebas y, posiblemente, un modo de supervisor que vuelve a ejecutar las pruebas a medida que guardas de ellos. Todas estas son opciones útiles para el desarrollo de una función nueva y son diseñada para facilitar la escritura de una función nueva, sus pruebas o ambas. con comentarios rápidos. Por ejemplo, Vitest funciona en modo de observador de forma predeterminada: El comando vitest buscará cambios y volverá a ejecutar cualquier prueba que encuentre. Mié te recomendamos dejarla abierta en otra ventana mientras escribas las pruebas, para que puedas recibir comentarios rápidos sobre tus pruebas a medida que las desarrollas.

Algunos ejecutores también te permiten marcar pruebas como only en tu código. Si el código incluye pruebas de only; solo estas se activarán cuando las ejecutes lo que agiliza y facilita la solución de problemas del desarrollo de pruebas. Incluso si todas tus las pruebas se completan rápidamente, el uso de only puede reducir la sobrecarga y quitar el una distracción en la ejecución de pruebas que no estén relacionadas con la función o la prueba en la que estés trabajando.

Para proyectos pequeños, en especial aquellos con un solo desarrollador, también puedes quieres desarrollar el hábito de ejecutar todo el paquete de pruebas de tu base de código con regularidad. Esto es muy útil si tus pruebas son pequeñas y se completan rápidamente (en ningún más de unos pocos segundos en todas las pruebas), de modo que pueda asegurarse de que todo está funcionando antes de continuar.

Ejecuta pruebas como parte del envío previo o la revisión

Muchos proyectos eligen confirmar que una base de código funciona correctamente cuando el código se volverá a combinar en su rama main. Si es la primera vez que realizas pruebas, han contribuido a proyectos de código abierto en el pasado, del proceso de solicitud de extracción (PR) confirma que todas las pruebas del proyecto pasar, lo que significa que tu nueva y emocionante contribución no ha afectado negativamente proyecto existente.

Si ejecutas las pruebas de manera local, el repositorio en línea de tu proyecto (por ejemplo, GitHub o algún otro servicio de hosting de código) no sabrán que tus pruebas son exitosas. por lo que ejecutar pruebas como tarea previa al envío deja en claro a todos los colaboradores que todo funciona.

GitHub, por ejemplo, se refiere a estas como “verificaciones de estado” que puedes agregar Acciones de GitHub. Las acciones de GitHub son En esencia, una especie de prueba: cada paso debe tener éxito (no fallar, ni arrojar Error) para que la acción pase. Puedes aplicar Acciones a todos los PR de un proyecto, y un proyecto pueden requerir que Actions se aprueben antes de contribuir con código. GitHub La acción predeterminada de Node.js ejecuta npm test como uno de sus pasos.

Este enfoque de prueba intenta garantizar que tu base de código siempre sea “verde” al no aceptar código que no ejecute correctamente sus pruebas.

Cómo ejecutar pruebas como parte de la integración continua

Una vez que se haya aceptado tu solicitud de extracción verde, la mayoría de las bases de código ejecutan pruebas de nuevo según en la rama main de tu proyecto, en lugar de en el PR anterior. Esto podría suceder de inmediato o con regularidad (por ejemplo, por hora o por noche). Estos los resultados se muestran a menudo como parte de un panel de integración continua (CI) que muestra el estado general del proyecto.

Este paso de CI puede parecer redundante, en especial para proyectos con bases de código pequeñas. pruebas aprobadas durante la revisión, de modo que deberían aprobarse una vez que se realice un cambio. Sin embargo, esto no siempre es así. Las pruebas pueden fallar repentinamente, incluso si se ejecutan produciendo resultados ecológicos. Estos son algunos de los motivos:

• Se aceptaron varios cambios "a la vez", que a veces se conoce como condición de carrera, y ambas se afectan entre sí de formas sutiles y no comprobadas.
• Las pruebas no se pueden reproducir o son inestables código, ambos pueden pasar y fallan sin cambios en el código.
  • Esto puede ocurrir si dependes de sistemas externos a tu base de código. Para un proxy, imagínate probando si Math.random() > 0.05; esto fallará de manera aleatoria un 5% de las veces.
• Algunas pruebas son demasiado costosas o costosas para ejecutarse en cada solicitud de extracción, como de extremo a extremo. pruebas (más información sobre los tipos de pruebas automatizadas), y pueden fallar con el tiempo sin generar alertas siempre.

Ninguno de estos problemas es imposible de superar, pero vale la pena darse cuenta de que las pruebas de rendimiento y el desarrollo de software en general, nunca será un la ciencia.

Interludio sobre la reversión

Cuando las pruebas se ejecutan como parte de la integración continua, incluso cuando las pruebas se ejecuta como parte de una verificación de estado, es posible que la compilación termine en estado, o bien otro estado que significa que las pruebas fallan. Como se mencionó anteriormente, esto puede suceder por varias razones, incluidas las condiciones de carrera en la prueba envíos o pruebas inestables.

Para proyectos más pequeños, tu instinto podría ser tratarlos como una crisis. Detener revertir el cambio ofensivo y regresar a un estado que el estado sea bueno. Este puede ser un enfoque válido, pero es importante recordar que las pruebas (y el software en general) es un medio para alcanzar un fin, no un objetivo en a sí mismo. Es probable que tu objetivo sea escribir software, no hacer que todas las pruebas sean exitosas. En su lugar, puedes adelantar haciendo un seguimiento del cambio rotundo con otro cambio que corrija las pruebas con errores.

Por otro lado, es posible que hayas visto o trabajado en proyectos grandes que existen siempre rota. O peor aún, el gran proyecto tiene una prueba inestable que se rompe con suficiente frecuencia como para causar fatiga por alarmas en los desarrolladores. A menudo, este es un problema existencial que deben resolver los líderes: incluso podrían desactivarse porque se consideran "interferir en el desarrollo”.

No hay una solución rápida para esto, pero puede ayudarte a escribir con más confianza. (desarrollo de la capacidad) y para reducir el alcance de las pruebas (simplificación) para que las fallas pueden identificarse con más facilidad. Una mayor cantidad de pruebas de componentes o pruebas de integración (más información sobre los tipos en Tipos de pruebas las pruebas) pueden brindar más confianza que una enorme prueba de extremo a extremo que es difícil de mantener y que se intenta realizar todo al mismo tiempo.

Recursos

• Cuáles son los beneficios de realizar compilaciones nocturnas

Verifica tus conocimientos