¿Cómo verifico que mis pruebas no fueron eliminadas por otros desarrolladores?

8

Acabo de encontrar un problema interesante de codificación colaborativa en el trabajo.

He escrito algunas pruebas de unidad / funcional / integración e implementado una nueva funcionalidad en la aplicación que tiene ~ 20 desarrolladores trabajando en ello. Todas las pruebas pasaron y revisé el código. Al día siguiente actualicé mi proyecto y noté (por casualidad) que algunos de mis métodos de prueba fueron eliminados por otros desarrolladores (fusionando problemas por su parte). No se tocó el nuevo código de aplicación.

¿Cómo puedo detectar ese problema automáticamente? Quiero decir, escribo pruebas para verificar automáticamente que mi código todavía funciona (o no se eliminó), ¿cómo hago lo mismo para las pruebas?

Estamos utilizando Java, JUnit, Selenium, SVN y Hudson CI si es importante.

— parxier
fuente

1

Ni siquiera estoy seguro de cómo eliminarías "accidentalmente" franjas enteras de código si realmente estás haciendo una extracción adecuada -> fusionar -> confirmar.

— Anon

@Anon, estoy seguro de que tampoco, él dice que estaba apurado y necesitaba comprometer su código rápidamente, por lo que no prestó mucha atención a la fusión de algo o algo. : - / De todos modos, todavía quiero detectar tales problemas automáticamente en el nivel de CI.

— Parxier

10

Y la persona "que tenía prisa" podría necesitar una conversación tranquila de un gerente, tal comportamiento es vago y no debe ser aceptable.

— rápidamente_ahora

1

Solo puedo imaginar que esto sería posible si la gente está registrando grandes cambios con muchos archivos modificados durante mucho tiempo. Normalmente no debería haber grandes fusiones donde incluso existe la posibilidad de que el código se "pierda" ... eso me parece la fuente real del problema.

— Dean Harding

1

Es por eso que nunca se debe permitir que un desarrollador individual se fusione con troncal en VCS centralizados. Los desarrolladores perezosos tienden a golpear las cosas de otras personas (he sido culpable de ello yo mismo).

— Chris K

4

No estoy muy familiarizado con Hudson para CI, pero mi herramienta de CI también puede calcular la cobertura de código. Si puede escribir un proceso que le notifique cuando la cobertura del código disminuya, sería un buen indicador de que se ha eliminado una prueba. También le dirá si se ha agregado un nuevo código sin pruebas. No es lo que estabas preguntando, pero es bueno saberlo.

— Marcie
fuente

3

Estaba a punto de mencionar este mismo punto en un comentario sobre la respuesta de Tim: el porcentaje de cobertura de su código nunca debería disminuir.

— Frank Shearar

Buen ángulo en una métrica!

¿Qué herramienta es esa, acaso?

— Chris K

@Chris, utilizamos TFS + TeamBuild, que he configurado para calcular la cobertura del código en cada Build.

— Marcie

No funcionará en este proyecto en particular porque la cobertura de prueba es bastante baja en este momento de todos modos, así que tengo que probar la idea de Tim. Pero me diste una buena solución y creo que es la mejor respuesta a mi pregunta.

— Parxier

12

Se aplican las exenciones de responsabilidad estándar: estamos haciendo una solución de ingeniería para un problema social. Sin embargo, este es un problema de higiene del proyecto, por lo que es un poco como decir que los inodoros son una solución de ingeniería para un problema social.

Tenga un trabajo en manos de la fuente RSS de Hudson. Cuente el número de pruebas en el informe Hudson. Si disminuye, haga sonar una alarma. Tener un auto-da-fe 'cuando suena la alarma.

La culpa del compromiso puede ser identificada y castigada. Tu problema desaparecerá.

Es posible que tenga otros problemas como resultado de esta solución. Si el mareo persiste, consulte a su médico.

— Tim Williscroft
fuente

1

+1: "estamos haciendo una solución de ingeniería para un problema social". Ese debería ser el final de la respuesta. El resto de la respuesta es menos valiosa que esa declaración.

— S.Lott

2

@SLott sí, pero si haces que sea fácil hacer lo correcto, se hará. Hemos utilizado un correo electrónico automático para todo el equipo, que se activó al romper la compilación. Funciona; Te vuelves más cuidadoso. Personalmente dudo de la utilidad de tratar de resolver este problema social. Si honestamente cree que eliminar las pruebas está bien, entonces la cultura de la empresa está en contra de la calidad.

— Tim Williscroft

Wow, soy portugués, y no tenía idea de qué es un auto-da-fé.

— R. Martinho Fernandes

El recuento de pruebas puede disminuir por razones válidas: una refactorización podría eliminar una clase y todas sus pruebas unitarias. Sin embargo, todavía vale la pena descubrir por qué disminuyó el recuento de pruebas.

— Frank Shearar

@Frank Supongo que sería importante si la frecuencia del recuento de pruebas disminuye por razones válidas en comparación con las inválidas. Si se trata principalmente de razones válidas, la alarma se ignorará después de un momento y no tendrá valor. Si son en su mayoría inválidos, entonces podría ser bueno. ¿Con qué frecuencia ocurre esto? Y en realidad, @parxier, si solo sucedió una vez que lo sabes, ¿podrías estar exagerando?

— James

2

Enfoque organizacional

Establezca una política que requiera que la persona elimine las pruebas para hablar con el creador de la prueba. Normalmente, eliminaría las pruebas solo cuando depreciara alguna funcionalidad que se está probando, y eso no sucede con mucha frecuencia.

Enfoque técnico

Este es más el enfoque de control freak pero puede tener una prueba por separado, que escanea el código fuente en busca de la presencia de todas las pruebas que desea verificar. Posiblemente también podría interactuar con Hudson y obtener la lista de pruebas ejecutadas.

— Arte
fuente

Las cosas se eliminaron durante una fusión. Tal vez por accidente, tal vez por pereza. La política no va a hacer mucho, aparte de más "deberás" de la administración que todos ignorarán. Sin embargo, una quema y flagelación pública podría llamar la atención. / sarcoff

— rápidamente_ahora

2

@quickly_now: "Las cosas se eliminaron durante una fusión". Eso debería ser un delito de despido. Cualquier organización que permita este comportamiento realmente necesita eliminar a muchas personas y reemplazarlas con personas que se esfuerzan por hacer algo sensato en lugar de malvado.

— S.Lott

Accidente: puedes perdonarlo la primera vez. Pereza o malicia, sí, delito de despido.

— rápidamente_ahora

Sería difícil mantener actualizada esa clase de prueba por separado, pero es una idea interesante, gracias.

— Parxier

0

Similar a la respuesta de Art ..

Comentarios Comience usando comentarios bien. Para cada método; no olvide colocar la entrada y salida esperadas, una breve descripción para funciones más complejas y su nombre.

Directrices Pero esto realmente resalta que existe la necesidad de una mayor comunicación entre el desarrollador. equipo. Debe haber pautas establecidas para trabajar juntos ... o al menos hablar con su proyecto. gerente y pedirle que aclare esto entre el equipo.

Uso adecuado de SVN También podría escribir sus clases y métodos y hacer un seguimiento de ellos ... también, mientras usa SVN, sinceramente espero que estas eliminaciones se sigan como cambios, se indiquen por separado y tengan BUENAS razones.

Además de escribir un programa especial, también podría comparar diff. archivos en SVN para rastrear cambios en sus métodos.

— Ross
fuente

0

Lo mismo podría suceder con el código real también, y no lo sabrá hasta que note que su cambio ya no existe.

Dicho esto, es difícil identificar que el código que se está eliminando es algo malo, ya que muy a menudo se eliminan manualmente el código / características, etc., y debido a eso, el recuento de pruebas puede disminuir tan bien como lo mencionó alguien más.

— ozz
fuente

Cuando se elimina el código, las pruebas se rompen. Cuando se eliminan las pruebas, nada se rompe.

— Parxier