cuándo deben realizarse las pruebas unitarias en un entorno de integración continua

7

Estamos tratando de adoptar algunas prácticas y metodologías de CI en nuestra organización. Actualmente estoy leyendo algunos de los puntos del libro "Entrega continua" escrito por Jez Humble y David Farley. Y el punto que estoy debatiendo es cuándo deben ejecutarse las pruebas unitarias, antes o después de que git se confirme. El libro parece sugerir la ejecución de pruebas unitarias después de registrarse, como parte de un conjunto de pruebas de confirmación. Pero, ¿no tendría más sentido realizar pruebas unitarias antes de registrarse?

Cualquier comentario sería apreciado.

    
pregunta Happydevdays 17.06.2016 - 20:54

3 respuestas

10

Por lo general, el desarrollador los ejecuta manualmente antes de registrarse, y un servidor de CI los ejecuta automáticamente después de registrarse. Los programadores suelen ser bastante buenos en la ejecución de pruebas unitarias para construcciones incrementales en la configuración en la que han estado trabajando, pero no lo hacen t hacer cosas como hacer una compilación limpia desde una verificación completamente limpia desde el control de versiones, ejecutar pruebas para todas las configuraciones de un producto, ejecutar todas las pruebas unitarias para los proyectos posteriores que dependen de las suyas, etc.

Es por eso que los servidores de CI "vuelven a ejecutar" las pruebas después de confirmar. Puede configurarlos para ejecutar las pruebas antes de que realmente se fusionen en una rama maestra, si desea una rama que definitivamente haya ejecutado todas las pruebas.

    
respondido por el Karl Bielefeldt 17.06.2016 - 21:08
2

La ejecución de sus pruebas automatizadas en su servidor CI es en realidad una forma de pruebas de integración.

Cuando un desarrollador ejecuta pruebas localmente, están validando si los cambios que hicieron se combinan con el estado de todo el sistema cuando verificaron su código .

Por otro lado, su servidor CI está integrando continuamente el trabajo de todos los desarrolladores. Cuando it ejecuta pruebas automatizadas, debe validar que los cambios del desarrollador se acoplan juntos correctamente.

    
respondido por el MetaFight 17.06.2016 - 21:44
0

La confirmación de pruebas rotas / código roto en su repositorio local no es problemática en sí misma. Los problemas comienzan a surgir cuando uno se compromete localmente con una rama de integración especialmente designada en anticipación de un impulso a un repositorio central. Los problemas reales surgen cuando uno empuja cosas rotas a una sucursal especialmente designada en un repositorio central.


Un sistema que impide completamente cometer pruebas rotas es un sistema roto. Si sigue el mantra de escribir pruebas antes de escribir código, las pruebas necesariamente fallarán al principio. Hacer que sea imposible cometer esas pruebas rotas intencionalmente no tiene sentido.

Un sistema que impide completamente cometer código roto también es un sistema roto. Los desarrolladores pueden comenzar con un pseudo código que ni siquiera se compila, luego proceder a un código real que no funciona, y finalmente a un código real que aparentemente funciona. Hacer que sea imposible cometer esas ideas iniciales no tiene sentido. Tener mi código roto en mi repositorio local ha salvado mi parte posterior más de una vez.

Robando palabras del Zen de Python, "la administración de la configuración es una gran idea, ¡vamos a hacer más de eso!"


Tiendo a trabajar en entornos esotéricos donde es imposible realizar pruebas locales completas (por ejemplo, supercomputadoras, redes de potentes no supercomputadoras, dispositivos integrados y redes de dispositivos integrados, ninguno de los cuales tengo en mi escritorio). Esto me hace un poco demasiado desconfiado de ganchos demasiado agresivos en un sistema CM.

Incluso si no trabaja en entornos esotéricos, tener un enlace de confirmación que active automáticamente las pruebas para cada confirmación individual (y luego rechace la confirmación en el caso de una falla) es solo una mala idea. Es mejor alentar a las personas a comprometerse con frecuencia y fusionarse con frecuencia. La fusión en una rama que contiene código no comprometido es una receta para una buena cantidad de angustia en la administración de la configuración. No fusionarse con frecuencia es una receta para una mayor angustia en la administración de la configuración.

El extremo opuesto, no tener ganchos en absoluto y luego hacer que los desarrolladores hagan cosas vergonzosas cuando rompen la compilación, también es una mala idea. Lo que se necesita es un compromiso que permita a las personas ser más eficientes y, sin embargo, protege contra las personas que hacen las estupideces que incluso las personas muy inteligentes suelen hacer.

    
respondido por el David Hammen 18.06.2016 - 01:18

Lea otras preguntas en las etiquetas