Cómo convencer a los miembros del equipo de la existencia de un "mandelbug"

Estamos desarrollando una aplicación; incluye una biblioteca desarrollada por otro codificador, esta biblioteca se comunica con el servidor a través de múltiples conexiones de red, y esto involucra múltiples hilos trabajando juntos. El código del lado del servidor es bastante complicado y no tenemos acceso al código fuente.

Recientemente descubrí que un mandelbug hace que la aplicación se bloquee a veces. Pude reproducirlo una vez y obtuve un seguimiento de la pila, así que abrí un informe de error. El error en sí es fácil de solucionar (excepción web no detectada en uno de los subprocesos en segundo plano, que hace que CLR finalice el programa).

El problema es que el desarrollador se niega a corregir el error, porque "no está convencido de que exista". Desafortunadamente para mí, el jefe está del lado de él y dice que este error no se puede solucionar a menos que haga un "caso de prueba sólido" para probar la existencia del error, y para hacer una prueba unitaria que verifique que se ha ido. Lo que es básicamente imposible debido a la naturaleza del error.

¿Algún consejo?

Si es posible, puede pasar algún tiempo para verificar si este defecto puede reproducirse poniendo un poco de suspensión o bloqueo en el código de su aplicación. Pero no pases demasiado tiempo. Como este problema se debe a múltiples encabezados (y también como observó), su ocurrencia será rara.

Mi consejo es no sudar demasiado por esto. Continúa tu trabajo. Siempre que se encuentre con este bloqueo, actualice su informe de errores con el seguimiento de la pila, diciendo que esto es una repetición y cambiando el propietario al desarrollador de la biblioteca. Deje que la gerencia / líder decida si corregirlo o no, dependiendo de su frecuencia.

Intenta también comprender la mentalidad del desarrollador. Dijiste "excepción web no capturada". El desarrollador en esta etapa puede no estar completamente seguro de cuáles serán otros efectos de atrapar esto . Entonces él / ella puede ser reacio a tocar el código.

Entonces, a partir de sus comentarios más o menos clarificadores, lo entendí de esta manera:

Está seguro de que solo falta un simple manejo adicional de excepciones, y ya sabe qué línea de código en la biblioteca es problemática y cómo se podría solucionar la biblioteca.

¿Por qué entonces no solo agrega las pocas líneas de código que faltan a la biblioteca usted mismo, le pide al equipo amablemente que pruebe la biblioteca con esos cambios? Asegúrese de que sea un cambio de bajo riesgo, fácil de entender por el desarrollador responsable de la biblioteca. Lo peor que podría pasar es que alguien tenga que revertir ese cambio en su VCS si su solución causa un nuevo comportamiento inesperado.

La mayoría de las personas son más fáciles de convencer cuando el trabajo ya está hecho. Además, reaccionan mejor en "aquí hay una solución mejorada", en lugar de "este código está mal, corríjalo de alguna manera".

EDITAR: cuando el desarrollador aún se niega a agregar ese cambio, la mejor opción es intentar que el código problemático funcione dentro de un arnés de prueba aislado donde simula el error de red. Trabajar eficazmente con código heredado describe muchas técnicas sobre cómo abordar este tipo de problemas. Por ejemplo, puede crear una versión de prueba de la biblioteca, que incluya solo los módulos y funciones problemáticos, y crear un "entorno simulado" a su alrededor donde pueda simular la "excepción de red" en condiciones controladas. A primera vista, puede parecer demasiado esfuerzo, pero una vez que tenga ese entorno, puede agregarle muchas pruebas adicionales (y supongo que eso tendrá sentido, ya que cuando el autor de la biblioteca se niega a agregar faltante) manejo de excepciones en un solo lugar,

Para un error como este, la prueba automática de fuzz (también llamada prueba aleatoria) podría ser útil para intentar reproducirla. Esto automatiza el proceso de encontrar el error al aleatorizar un conjunto fijo de parámetros (o entradas) en lo que está probando. En cada ejecución de prueba, los parámetros se registran en un archivo de registro, incluidas las marcas de tiempo, etc., de modo que cuando se produce el bloqueo, puede (en teoría) simplemente volver a reproducir la prueba, utilizando los mismos parámetros, para reproducirla.

Como está automatizado, el proceso de prueba puede ejecutar muchas pruebas en un corto período de tiempo. A menudo se puede dejar que se ejecute durante la noche, y en la mañana puede consultar un archivo de registro para ver si reprodujo el bloqueo.

El abogado del diablo sugiere otro camino.

El otro desarrollador ha declarado, rotundamente, que no hay ningún error allí.

¿Puedes encontrar una manera de estresar su infierno supuestamente inexistente y hacer que se bloquee con mucha más frecuencia?

El seguimiento de la pila es una clara evidencia de que el error existe, o al menos existió en una determinada compilación. Lo que no tiene es evidencia de que se solucionó el error. Son tontos por ignorarlo. He tenido errores "imposibles de reproducir" después de cientos de miles de intentos automatizados en múltiples sistemas que se activaron cada vez en el sistema de un cliente.

Recibo un par de errores por año, la mayoría sin siquiera el beneficio de un seguimiento de la pila. En casi todos los casos, aunque no pude reproducirlo de antemano, pude hacer una prueba automática una vez que se solucionó.

Por ejemplo, hace unos meses arreglé un error que solo ocurría cuando el usuario escribía más de 96 palabras por minuto. Antes de arreglarlo, todo lo que sabía era que el error ocurría "a veces". Nunca se me ocurriría escribir una prueba unitaria para escribir rápidamente. Sin embargo, después de conocer la causa raíz, hacer una prueba fue trivial.

Incluso en esos raros casos en los que un error no puede reproducirse incluso después de ser reparado, puede cerrarlo mediante inspección de código.