Cómo convencer a los compañeros de equipo para usar TDD [cerrado]

Soy la única persona en mi equipo que usa TDD. ¿Cómo hago para que lo usen?

Me molesta que cuando tire, el código de alguien rompa mis pruebas y yo sea quien tenga que arreglarlo.

¿Usar github, fork y pull request resolverá este problema, por lo que deben pasar la prueba antes de que se acepte el pull?

No soy el gerente del proyecto y parece que no puedo convencerla de que lo use.

A mi modo de ver, la única forma de convencer de las pruebas es demostrar que son útiles, es decir, que los fallos en las pruebas ayudan a encontrar y corregir errores .

Sin embargo, la forma en que describe el problema parece que este no es el caso aquí. Mira...

... cuando tire, el código de alguien romperá mis pruebas y yo soy quien tiene que arreglarlo.

Si entiendo correctamente, quiere decir que tiene que modificar las pruebas. Bueno, eso no parece que las fallas de prueba ayuden 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 ganar? tediosas correcciones en el código de prueba frágil?

Esto puede sonar como un callejón sin salida, pero realmente no lo es. Su objetivo final (convencer para TDD) todavía tiene bastante sentido, no lo deje caer. Simplemente vuelva a centrar sus esfuerzos en eliminar el obstáculo que descubrió.

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. Úselos como una oportunidad para mejorar las pruebas, para aprender a hacer un buen diseño de prueba confiable. Trabaje en las 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 descubra errores reales, infórmeles a sus colegas y ayúdelos a solucionarlos, y no olvide señalar que sus pruebas encuentran estos errores. Eso hará 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 serán necesarias nuevamente, si (cuando :) finalmente convenza a sus compañeros de equipo de usar TDD. Piénsalo...

... ¿Qué sucedería cuando se presente el desarrollo impulsado por pruebas a sus colegas sin experiencia?

Lo primero que se debe esperar es que los muchachos comiencen a escribir exámenes malos y (¡horror!) Incluso rompan los buenos mientras aprenden. Para ayudarlos a encontrar una manera de hacerlo bien, necesitará una comprensión bastante sólida del buen diseño de la prueba.

Todos los errores que encuentre y solucione en sus pruebas ahora, serán repetidos una y otra vez por todos sus compañeros de equipo cuando comiencen a aprender. Si (¡cuándo!) Eso sucede, es mejor que esté preparado para explicar rápida y claramente cómo mejorar si desea que sigan siendo positivos sobre TDD.

Cuando quería alentar el uso de Test Driven Development , ejecuté un Cyber-Dojo . Con este tipo de ejercicio, el énfasis no está en el código en sí, sino en el proceso de escribir el código .

Pasamos una tarde, en parejas, repitiendo el mismo kata, pero en diferentes condiciones. Comenzamos con todos los grupos haciendo un ejercicio al mismo tiempo. Esto proporcionó una línea de base.

Luego discutimos algunos de los principios básicos de TDD, hicimos que todos cambien de pareja y repitan el mismo kata. Repetimos el mismo kata para restar importancia a la generación de código y, en cambio, concentrar a las personas en el proceso de nombrar casos de prueba y el ciclo Rojo / Verde.

Luego repetimos el kata nuevamente, pero aproximadamente cada 10 minutos una persona en cada grupo se mudaría a otro grupo, simulando los entornos de equipo bastante fluidos en los que nos encontramos en estos días.

En la iteración final, hicimos que ambos socios cambiaran cada 10 minutos más o menos en diferentes grupos. Esto ayudó a demostrar que con TDD, incluso la transferencia de un equipo a otro completamente diferente no necesariamente tiene que ser demasiado dolorosa, ya que el proyecto solo debería ser un ciclo Rojo / Verde de funcionamiento.

Lo interesante fue que había pocas personas que habían hecho algún TDD antes de la sesión, pero el conocimiento de TDD allí se extendió rápidamente hasta que en la iteración final a través del kata, la mayoría de la gente pensaba de forma TDD o al menos podía apreciar por qué podría ser beneficioso

La gente generalmente dijo que la tarde fue divertida e informativa y ahora estamos buscando otras formas de usar Cyber-Dojo en mi lugar de trabajo.

Cyber-Dojo , escrito por Jon Jagger , funciona increíblemente bien para este tipo de ejercicio. Es un entorno basado en web integrado para hacer la práctica deliberada de TDD y aprender sobre la dinámica del equipo. Tiene muchos katas seleccionados específicamente para ayudar a las personas a concentrarse en el proceso de TDD y no en el problema. También es compatible con una variedad de lenguajes, desde Python y Ruby hasta Java y C ++.

Lo mejor es que, después de hacer un kata, puedes volver y mirar la progresión roja / verde (o tal vez no * 8 ') de cada uno de los grupos participantes. Sus semáforos son una excelente manera de visualizar cómo funciona el proceso TDD.

Si desea su propio servidor CyberDojo, todo el proyecto se puede encontrar en github e incluso hay una máquina virtual de dispositivo Linux llave en mano vinculada desde allí, lo que significa que suponiendo que ya tenga instalado VMware player o VirtualBox , puede estar funcionando dentro de ¡unos minutos de descarga del dispositivo!

Si se resisten a TDD, está bien. Muchas personas (incluyéndome a mí) están teniendo problemas para escribir pruebas unitarias primero.

Sin embargo, debe plantear una pregunta acerca de no tener pruebas unitarias en absoluto, y el problema de la ruptura de las pruebas unitarias. Las pruebas unitarias son una red de seguridad que previene muchos posibles errores y permite la refactorización del código. Explicar sobre una mayor calidad de código y un código más limpio.

Creo que lo mejor sería encontrar un video que explique las ventajas de usar TDD y mostrarlo en una reunión.

Si ella se niega a escuchar, entonces puedes tratar de ir a alguien por encima de ella, pero eso podría no ser muy inteligente si tu jefe es tan terco.

Es realmente difícil convencer a la gente de cambiar sus hábitos, pero aquí hay algunas cosas que puede probar:

• Hable con los otros desarrolladores y explíqueles por qué piensa que TDD es una buena idea.
• Convencerlos (o al menos algunos de ellos) a probarlo por un tiempo limitado
• Intente establecer algunos requisitos mínimos para trabajar bien en equipo. No necesariamente tienen que hacer TDD, pero ciertamente no deberían estar registrando el código que está fallando en las pruebas unitarias. Este es un tema aparte de convencerlos de usar TDD y es mucho más importante abordarlo.
• Intente convencer a la gerencia para que aplique un período de prueba para TDD. Deberá estar preparado para proporcionar evidencia sobre por qué es una buena práctica y cómo le ahorrará tiempo y dinero a la compañía en el futuro.

Si nada de esto funciona, es posible que desee considerar trabajar en otro lugar. Hay muchas otras compañías donde su vida sería considerablemente más fácil.

Aquí hay 2 problemas ligeramente diferentes: hacer que las personas hagan TDD y que las personas rompan sus pruebas.

No estoy seguro sobre el primer problema, personalmente me parece una forma artificial de trabajar y no se adapta a todos los tipos de desarrollo. Estoy a favor de tener un buen conjunto de pruebas unitarias, pero generalmente me resulta más eficiente escribir primero el código y luego las pruebas, ya que mientras escribo el código mis ideas siempre cambian, y es una pérdida de tiempo escribir pruebas también temprano (IMO).

En el segundo problema, configure el proyecto para que las pruebas unitarias se ejecuten en el check-in, para que otros desarrolladores no tengan más remedio que saber que han roto una prueba.

Como se dijo en muchos otros "¿cómo debería convencer a X para que use el método / tecnología Y", mi respuesta es siempre la misma: por ejemplo.

Úselo y obtenga mejores resultados (mesurables). Luego asegúrese de que los demás lo noten.

En un proyecto existente, no. Es lo mismo que si estuviera haciendo cambios en la forma en que se colocan las llaves en el código heredado porque no le gusta el estilo de sangría.

Un montón de buenos consejos. Y ahora, un poco más ...

Debes ganar corazones y mentes (WHAM) un ludita a la vez. Olvídate de forzarlo por sus gargantas. Muchas lecciones objetivas durante un período de tiempo indefinido (perdón por eso). Eventualmente alcanzará una masa crítica, convencerá a las personas "correctas".

Su constante y constante entusiasmo y vocación por TDD es muy importante en una campaña WHAM.

Debes convertir los cambios de prueba y de código en momentos de enseñanza, las lecciones que son importantes para tus codificadores. Hazlo personal. IE ¿Les importa una reputación de entregar código limpio por encima del promedio? ¿Les importa que la administración los critique con respecto al código que ahora llega tarde porque los probadores de integración les dieron una verificación de la realidad? ¿Tiene Jack el deseo de modificar algún código difícil pero tiene miedo de los efectos secundarios?

Reúna buenos ejemplos de pruebas de éxito como atrapar errores inducidos por el codificador. Los codificadores verán las pruebas cambiantes como un trabajo innecesario para un código irrelevante; deben entender que las pruebas solo cubrieron sus traseros.

Encuentre un código con implicaciones globales (algún método de utilidad simple), cree algunas pruebas, luego demuestre que las pruebas permiten cambios sin temor a terremotos en toda la aplicación. ¡Y también quiero enfatizar el tema emocional!

Reúna algunos ejemplos simples de tiempo para limpiar el código (es decir, pasados ​​a producción) y demuestre que, a pesar del esfuerzo adicional para la codificación de prueba , la hicimos más rápido y con mayor calidad.

Advertencia: TDD no es una cura y no puede superar el mal diseño y codificación de OO (pero definitivamente puede exponerlo). No dejes que los luditas culpen al esfuerzo del código de prueba por su incompetencia.

Intentaría intentar nuevamente convencer al gerente. Por lo que has escrito, no creo que puedas convencer a tus compañeros de equipo para que hagan TDD a sus espaldas.

Tienes que hablar su idioma. Los gerentes tienden a no quedar impresionados con la tecnología, pero entienden el lenguaje comercial:

• las pruebas ahorrarán tiempo durante el desarrollo, porque en lugar de las pruebas manuales (tratando de reproducir errores localmente, jugando con la consola de rails ...), ejecutará pruebas automáticamente

• La prueba ahorrará mucho tiempo durante el mantenimiento de la aplicación, cuando puede detectar fácilmente errores cada vez que cambie algo. Explique que las pruebas requieren una mayor inversión inicial, pero que se pagarán a largo plazo (el mantenimiento de buenas pruebas suele ser rápido y fácil)

• ¿Y qué harás con el tiempo extra? crear cosas de moar y hacer que lloren dinero :)

En cuanto a los programadores, pruebe este argumento (funcionó para mí, hace mucho tiempo): "De todos modos, está probando código, con o sin TDD. Solo lo hace manualmente en lugar de automatizarlo. Los desarrolladores inteligentes automatizan tantas cosas como pueden". "

En proyectos reales con plazos, las personas quieren centrarse en hacer el trabajo con lo que saben. Eso es solo la naturaleza humana. Y si nunca aprendiste TDD, serías igual que ella en esta situación. Lo guardo.

¿Por qué la multitud de recolectores de basura no ama, aprende y vive RAII? ¿Cómo podría defender la administración automática de memoria pero aferrarse a la administración tradicional para recursos generales como archivos, conexiones, etc.? Debido a que RAII es una tecnología que no conocen, entienden y no tienen tiempo de usar cuando tienen una fecha límite que necesita trabajo.

Apuesto a que no usa RAII y no está dispuesto a aprenderlo y comprenderlo para su proyecto actual. Lo mismo que su compañero de trabajo que no está dispuesto a aprender y comprender TDD.