Recordando ejecutar pruebas antes del commit

Question

Tenemos un conjunto decente de pruebas unitarias en nuestro código y esas pruebas unitarias se ejecutan en menos de 2 minutos. También usamos TeamCity para hacer una compilación y ejecutar pruebas después de cada check in. Sin embargo, todavía tenemos problemas donde un desarrollador "olvida" ejecutar todas las pruebas antes de una confirmación que da como resultado una falla de TeamCity que si esta verificación se realiza a las 6PM puede permanecer roto durante la noche.

"Forgets" es un término genérico, hay otras dos razones comunes por las que incluso recordar ejecutar las pruebas podría provocar el fracaso de TeamCity. Como.

-> Un desarrollador solo comprueba algunos de los archivos modificados en su espacio de trabajo.
-> Un archivo se modificó fuera de eclipse de modo que la perspectiva de sincronización del equipo de eclipse no lo detecta como sucio.

¿Cómo maneja esto en su organización?

Estamos pensando en presentar un "procedimiento de registro" para los desarrolladores que será una herramienta automatizada que automáticamente ejecutará todas las pruebas unitarias y luego enviará todos los archivos "sucios" en su área de trabajo. ¿Has tenido alguna experiencia con dicho proceso? ¿Conoce alguna herramienta que pueda facilitar este proceso? Nuestro entorno de desarrollo es Python usando el complemento PyDev de Eclipse.

Answer 1

Para mercurial puede usar ganchos, que ejecutarán pruebas y solo permitirán el éxito. Pero esto puede requerir mucho tiempo para un empujón (pero el desarrollador tiene que ejecutar esas pruebas de todos modos).

O simplemente puede tener su propio conjunto de scripts bash, que ejecutará la prueba y solo luego ejecutará el comando de confirmación. Por ejemplo, para Django y svn commit podría parecer tan simple como esto:

./manage.py test && svn commit $@ 

O hay otra manera: si alguien comete código, que no pasa la prueba, que paga alguna suma. Pronto la gente recordará probar, porque no les gustará la idea de pagar dinero ;-)

Answer 2

Creo que es más un problema social que una deficiencia de los sistemas automatizados.

Sí, puede mejorar los sistemas en su lugar, pero no podrán competir con alguien que piense en las implicaciones de su compromiso, y probarlo antes de que lleguen al compromiso.

Answer 3

En uno de los equipos que estaba trabajando antes teníamos un acuerdo de que cualquiera que rompa las pruebas compra sandwiches de tocino para todo el equipo a la mañana siguiente. ¡Es extremo, pero funciona perfectamente!

Answer 4

TeamCity tiene compatibilidad con pretested commit; si su equipo de desarrollo usa un IDE soportado, puede investigar eso.

En mi compañía, no nos preocupamos demasiado, nuestro patrón se ve así.

(a) cada desarrollador tiene su propia configuración de proyecto en TeamCity, con las raíces apuntando a su propia zona de pruebas. Se les permite hacer lo que quieran aquí.

(b) el equipo de desarrollo tiene una zona de pruebas de integración, donde se entregan todos los cambios. Un proyecto encapsula las configuraciones que supervisan esta rama en el sistema de control de origen. Dev Leads puede inventar las reglas aquí, pero esa regla casi siempre es "debe mantenerse verde". Tendría que ver el porcentaje exacto de compilaciones limpias, no es un registro perfecto, pero es lo suficientemente alto como para que nunca haya tenido la tentación de insistir en que los desarrolladores sean más disciplinados con la ejecución de pruebas.

(c) la entrega real proviene de una transmisión principal, que permanecerá verde (tm). Dev Lead es responsable de entregar una instantánea clara de la integración a la transmisión principal en un cronograma bien definido. Este proyecto es el que realmente genera los instaladores que se envían a las pruebas, los bits que ingresan en el depósito en garantía, etc.

Una razón por la que puede obtener una forma más agresiva que nosotros es que nuestro ciclo de compilación es lento, del orden de cuatro horas. Si fuéramos un orden de magnitud más pequeño, con una tasa de éxito pobre, podría argumentar un caso diferente.

Answer 5

Para git puede: http://francoisgaudin.com/2011/02/16/run-django-tests-automatically-before-committing-on-git/

Run Django automáticamente prueba antes de comprometerse en Git

Dado que a menudo se olvide de ejecutar pruebas unitarias antes de comprometerse, paso mucho de tiempo buscando el mal confirmar cuando encuentro regresiones 3 commits later.

Sin embargo, es muy fácil ejecutar pruebas automáticamente antes de cada compromiso. En .git/ganchos/pre-commit, poner:

python manage.py 
test exit $? 

continuación chmod 755 este archivo y se hace. Me encanta git :-)

No olvides utilizar tu virtualenv antes de comprometerte.

Tenga en cuenta que las pruebas se ejecutan en su árbol de trabajo y no en el commit , por lo que si compromete solo una parte de su árbol de trabajo, puede fallar mientras su confirmación pasa las pruebas.