Respuesta.

Un versionado e integración adecuada de las pruebas automáticas son críticos para garantizar que la verificación esté alineada con el estado actual del proyecto.

Historia del problema

Inicialmente, las pruebas automáticas se realizaban a menudo por separado del proyecto principal, lo que llevaba a incompatibilidades y problemas de mantenimiento. El desarrollo de múltiples ramas, lanzamientos frecuentes de software y pruebas — generó la necesidad de un sistema de control de versiones común.

Problema

Sin versionado e integración coordinada, surgen:

Ejecución de pruebas no actualizadas en el software modificado
"Ruptura" de pruebas al desplegar nuevas funciones, sin tener en cuenta los cambios en las pruebas
Fallos en CI/CD

Solución

Enfoque moderno:

Las pruebas se almacenan en un sistema de control de versiones común (generalmente git)
Vínculo de la rama de pruebas a la rama de desarrollo del software: en la rama de función — las pruebas y el código van juntos
Comprobaciones/construcciones automáticas se realizan mediante pull requests
Revisión y aprobación de cambios en pruebas y código

# Enfoque general:
git checkout -b feature/new_login
# La función y las pruebas se desarrollan y prueban juntas
# Después de la revisión se fusionan juntas en la rama principal

Características clave:

Consistencia en los cambios de código y pruebas (sin desincronización)
Fácil reversión y comparación de versiones (a través del historial de git)
Posibilidad de trabajo en equipo y revisión de código de pruebas automáticas

Preguntas capciosas.

¿Se pueden almacenar las pruebas en un repositorio separado (del código del proyecto)?

Sí, pero entonces es más difícil mantener la actualidad de las pruebas, se requiere sincronización manual, hay riesgo de "olvidar" actualizar algo al realizar un lanzamiento o una corrección de errores.

¿Las pruebas deben cubrir todo el nuevo funcionalidad al crear un PR?

Idealmente — sí, pero en la práctica muchas veces cubren MVP/espectros principales en el primer PR, y casos complejos — como tareas separadas. Lo principal es que la funcionalidad crítica esté cubierta de inmediato.

¿Se pueden revertir solo los cambios en las pruebas sin revertir el código?

Si las pruebas y el código están juntos en una misma rama — sí, se pueden revertir las revisiones. Pero es mejor evitar la "reversión" de pruebas sin el código: esto deteriora la calidad de la verificación.

Errores comunes y anti-patrón

Almacenamiento de pruebas no en git, sino en sistemas de archivos
Conducción de pruebas en un repositorio separado sin una conexión clara con el proyecto
Incorporación de pruebas desde fuera (post factum), y no simultáneamente con el código

Ejemplo de la vida

Caso negativo

Proyecto con un repositorio separado de pruebas automáticas. Después del lanzamiento, los programadores "olvidaron" actualizar las pruebas — las pruebas fallaban, se realizaban verificaciones no actualizadas, se encontraban errores en producción.

Ventajas:

Los programadores podían trabajar independientemente del QA

Desventajas:

Pérdida de tiempo en la sincronización, presencia de pruebas "obsoletas"

Caso positivo

Las pruebas y el código del proyecto se llevan en una misma rama de git: en cualquier nuevo pull request, las pruebas automáticas se actualizan obligatoriamente para el código añadido. Todos los cambios pasan por revisión de código y comprobaciones automáticas.