Pruebas unitarias antiguas / heredadas rotas

Lo que haría es primero deshabilitar las pruebas que fallan y siempre fallan.

Haz que la prueba falle.

A medida que investigue, es posible que pueda preguntarles a las personas que han estado más tiempo con su empresa, puede haber un gran conocimiento tribal sobre ellos que puede documentar / capturar. Tal vez de sus registros VCS. "Oh, esa prueba siempre ha fallado desde que actualizamos a X" u otra información puede ser útil.

Una vez que sepa cuál fue la funcionalidad que se está probando, puede determinar:

• ¿Nos preocupa que esto sea probado?
• ¿Qué tan importante es esto para ser probado?

Y luego haz una lista de prioridades.

Es probable que nada en esta lista sea lo suficientemente importante como para tener más tiempo después, ya que ha sido ignorado por años. Por lo tanto, no gastaría demasiado mucho tiempo / recursos en documentar y analizar todas estas pruebas fallidas.

Yo haría lo siguiente:

1. Intente determinar exactamente qué intentan validar las pruebas que fallan.

2. Triaje: si algunas pruebas intentan probar cosas sin importancia como (un estado antiguo) del mundo, elimínelas. Si te das cuenta de que algunos de ellos están tratando de validar algo importante, trata de determinar si esas pruebas lo están haciendo correctamente. Si están realizando una prueba incorrecta, hágales la prueba correctamente.

3. Corrija cualquier problema con su código de producción ahora que tiene buenas pruebas.

Recuerde que la contabilidad, cada línea de código es un pasivo, pero se puede valorar incorrectamente como un activo. La tecla eliminar puede crear mucho valor para su empresa.

  

200-300 exámenes rotos (probablemente rotos durante años).

¡Ay! Una vez me enfrenté a una situación similar, pero fallaron 7 pruebas en las que el equipo comenzó a ignorar el hecho de que fallaron durante meses debido a la mentalidad de "siempre en crisis".

  

Mi objetivo es pasar las pruebas al 100% para que podamos romper la compilación en la prueba unitaria   fallos, pero no puedo hacerlo hasta que abordo las pruebas rotas.

Estaba obsesionada con un objetivo similar, aunque solo era un desarrollador junior en el equipo porque estaba notando un montón de pruebas en las que más pruebas fallaban a lo largo de los meses. Quería que convirtiéramos esos "avisos" en errores de compilación (tal vez algo molestos para el resto del equipo).

  

Estoy pensando que deberíamos documentar los estados de las pruebas rotas con   todo lo que sabemos, entonces borre o ignore las pruebas rotas   completamente e ingrese un error / elemento de trabajo de menor prioridad para investigar y   arreglalos. Entonces estaremos al 100% y comenzaremos a obtener un valor real de la   Otras pruebas y si tenemos una ganancia inesperada de mantenimiento / refactorización estaremos   capaz de recogerlos de nuevo.

Estos son mis pensamientos también. Puede desactivar temporalmente todas estas pruebas defectuosas y visitarlas lentamente y corregirlas con el tiempo. Sin embargo, es importante programar esas correcciones si las considera realmente importantes, incluso si son de baja prioridad, ya que es fácil que dichos elementos simplemente se queden sin fijar. La prioridad para mí es asegurarse de que no se introduzcan nuevas pruebas que fallen.

Como cualquier tipo de advertencia, si no rompen la construcción, tienden a acumularse rápidamente. Esto es asumiendo ese tipo de dinámica de equipo donde el hábito de ignorar las advertencias (pruebas fallidas en este caso) puede llevar rápidamente a que se introduzcan más advertencias, y reducir la tentación de mantener esas advertencias en cero.

Es posible que un equipo muy concienzudo no sufra estos problemas y evite introducir nuevas advertencias (nuevos fallos en las pruebas), pero definitivamente es más seguro ir un poco más torpe y ejercer una estrategia de prevención al convertirlos en errores que debe arreglarse antes de un proceso de fusión.

Por lo tanto, mi sugerencia es la misma que la suya (aunque solo sea una opinión fuerte, quizás de alguna manera pueda respaldar esto con métricas y una respuesta más científica). Deshabilite esas pruebas antiguas y colóquelas en el calendario para corregirlas. La primera prioridad es asegurarse de que este problema no se acumule y empiece a empeorar asegurándose de que las pruebas que actualmente tienen éxito no se ignorarán en última instancia si comienzan a fallar.

De alguna manera tienes suerte. Es mejor tener pruebas que fallen y no deberían (le advierten al menos que algo está mal) que las pruebas que pasan y no deberían (lo que le da una falsa sensación de seguridad). Por supuesto, si tiene el primero, es muy probable que también tenga el segundo (por lo que las pruebas pasan pero deberían estar fallando).

Como ya se ha indicado, por ahora deshabilite esas pruebas fallidas, pero pídales que impriman un mensaje en su registro de prueba como un recordatorio constante sobre ellas.
Pero definitivamente debería encontrar los recursos para revisar todo su conjunto de pruebas para encontrar y eliminar las pruebas que pasan y no debería, porque cada una de ellas significa que hay un error en su código que actualmente no está detectando en su ciclos de prueba.

Al usar esa nube oscura sobre la base del código, es posible que pueda obtener un presupuesto para una revisión completa de sus pruebas, si juega bien y no solo les dice que cree que se deben examinar algunas pruebas porque parecen falla cuando no deberían, pero no confías en que tus pruebas detecten errores en tu código correctamente, que no se puede confiar en que el conjunto de pruebas haga su trabajo. Cuando hice eso en una empresa anterior en la que trabajaba para una revisión de este tipo, descubrí que cientos de pruebas se escribieron con suposiciones incorrectas sobre lo que el código DEBERÍA hacer, lo que llevó a que el código (que se escribió utilizando las mismas suposiciones incorrectas) aprobara las pruebas cuando Realmente no debería haberlo hecho. Arreglar esto resolvió muchos errores desagradables en el caso de una esquina que (aunque la mayoría no eran críticos) podrían haber derribado algunos sistemas importantes.

Cualquier prueba de unidad fallida debería causar que la construcción se rompa. Bien por ti por realizarlo y establecer ese objetivo. La mente humana no puede ignorar nada más completamente que la fuente de una falsa alarma persistente .

Deseche estas pruebas y no mire hacia atrás. Si han estado fallando durante años y no se han abordado hasta ahora, entonces no son una prioridad.

En cuanto al conocimiento tribal, si las personas con el conocimiento tribal todavía están alrededor, ya deberían haber arreglado las pruebas que fallaron. Si no, una vez más, estos no son una prioridad.

Si no hay conocimiento tribal, usted y su equipo deben tomar posesión de la lógica. Las pruebas que fallan pueden ser más engañosas que útiles, el mundo puede haber avanzado.

Cree nuevas pruebas que sean relevantes y empiece a escribir un gran código.