La forma en que lo veo, la única manera de convencer de algo acerca de las pruebas es demostrar que son útiles, es decir, que las fallas en las pruebas ayudan a encontrar y corregir errores .
La forma en que describe el problema, sin embargo, parece que este no es el caso aquí. Mira ...
... cuando tire, el código de alguien romperá mis pruebas y yo soy el que tiene que corregirlas.
Si entiendo correctamente, quiere decir que tiene que modificar las pruebas. Bueno, eso no suena como las fallas de prueba ayudan a encontrar y corregir errores , ¿verdad? Si las pruebas no ayudan a encontrar errores, es una posición bastante débil para comenzar a convencer a sus colegas: ¿qué podrían esperar obtener? ¿Reparaciones tediosas en código de prueba frágil?
Esto puede parecer un callejón sin salida, pero en realidad no lo es. Su objetivo final (convencer para TDD) todavía tiene bastante sentido, no lo deje caer. Simplemente enfoca tus esfuerzos en eliminar el obstáculo que descubriste.
Las fallas de prueba que le molestan ahora son esencialmente "alertas falsas", lo que significa que son errores en las pruebas que no están en el código. Utilícelos como una oportunidad para mejorar las pruebas, para aprender cómo hacer un buen diseño de prueba confiable. Trabaje en pruebas para que las "alertas falsas" sean menos frecuentes y para que sea más fácil descubrir errores reales en el código probado.
A medida que descubres errores reales, avísales a tus colegas y ayúdalos a solucionarlos, y no olvides señalar que estos errores se encuentran en tus pruebas. Eso creará un terreno realmente sólido para convencer a sus colegas.
Vale la pena mencionar que las habilidades de diseño de prueba que desarrolle en la etapa "preliminar" probablemente sean necesarias nuevamente si (cuando :) finalmente convenza a sus compañeros de equipo para que usen TDD. Piénsalo ...
... ¿Qué pasaría cuando el desarrollo basado en pruebas se presente a sus colegas inexpertos?
Lo primero que se debe esperar es que los chicos comiencen a escribir pruebas de mierda e (¡horror!) incluso rompiendo las buenas mientras aprenden. Para ayudarles a encontrar la manera de hacerlo correctamente, necesitará una comprensión sólida del buen diseño de las pruebas.
Todos los errores que encuentre y corrija en sus pruebas ahora, se repetirán una y otra vez por todos sus compañeros de equipo cuando empiecen a aprender. Si (cuando!) Eso suceda, será mejor que esté preparado para explicar rápida y claramente cómo mejorar si desea que se mantengan positivos con respecto a la TDD.