Soy la única persona en mi equipo que usa TDD. ¿Cómo los hago para usarlo?
Me molesta que cuando tire, el código de alguien rompa mis pruebas y yo sea quien tenga que corregirlos.
¿Resolverá este problema el uso de github, fork y pull request para que tengan que pasar la prueba antes de que se acepte el pull?
No soy el gerente del proyecto y no puedo convencerla de que lo use.
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.
Cuando quise alentar el uso de Development Driven Development ejecuté un Cyber-Dojo . Con este tipo de ejercicio, el énfasis no está en el código en sí, sino en el process de escribir el código.
Pasamos una tarde, en parejas, repitiendo el mismo kata, pero bajo 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 cambiaran de pareja y repitieran el mismo kata. Repetimos el mismo kata para reducir el énfasis en la generación de código y, en cambio, concentrar a las personas en el proceso de asignación de nombres a los casos de prueba y el ciclo Rojo / Verde.
Luego repetimos el kata de nuevo, pero aproximadamente cada 10 minutos una persona de cada grupo pasarí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, tuvimos ambos socios que se cambian cada 10 minutos aproximadamente en diferentes grupos. Esto ayudó a demostrar que con TDD, incluso el traspaso de un equipo a otro completamente diferente no tiene por qué ser demasiado doloroso, ya que el proyecto solo debe estar a un ciclo Rojo / Verde del trabajo.
Lo interesante era que había pocas personas que habían hecho un TDD antes de la sesión, pero el conocimiento de TDD allí se difundió 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 Aprecie 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 integrado basado en web para hacer práctica deliberada de TDD y aprende 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 admite una variedad de idiomas, desde Python y Ruby hasta Java y C ++.
Lo mejor es que, después de hacer un kata, puedes regresar y observar la progresión rojo / verde (o quizás no * 8 ') de cada uno de los grupos participantes. Los semáforos son una excelente manera de visualizar cómo funciona el proceso TDD.
Si quieres tu propio servidor CyberDojo, el proyecto completo se puede encontrar en github e incluso hay una Máquina virtual del dispositivo Linux llave en mano enlazada desde allí, lo que significa que suponiendo que ya tiene VMware player o VirtualBox instalado, puede estar en funcionamiento unos minutos después de descargar el electrodomestico!
Si resisten TDD, está bien. Muchas personas (incluido yo mismo) tienen problemas para escribir las pruebas unitarias primero.
Sin embargo, debe plantear una pregunta sobre la falta de pruebas unitarias 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 de códigos. 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 intentar ir con alguien que esté por encima de ella, pero eso no sería muy inteligente si tu jefe es tan terco.
Es realmente difícil convencer a las personas para que cambien sus hábitos, pero aquí hay algunas cosas que puede probar:
Si nada de esto funciona, es posible que desee considerar trabajar en otro lugar. Hay muchas otras compañías en las que tu vida sería mucho más fácil.
Aquí hay 2 problemas ligeramente diferentes: lograr que las personas realicen TDD y que las personas rompan sus pruebas.
No estoy seguro acerca del primer problema, personalmente me parece una forma artificial de trabajar y no es adecuado para todos los tipos de desarrollo. Estoy a favor de tener un buen conjunto de pruebas unitarias, pero por lo general me parece más eficiente escribir primero el código y luego las pruebas, ya que mientras escribo el código mis ideas siempre están cambiando, y también es una pérdida de tiempo escribir las pruebas temprano (IMO).
En el segundo tema, configura el proyecto para que las pruebas unitarias se ejecuten en el registro, para que otros desarrolladores no tengan más remedio que saber que han roto una prueba.
Un montón de buenos consejos. Y ahora, un poco más ...
Debes ganar corazones y mentes (WHAM) uno Luddite a la vez. Olvida sobre forzarlo por sus gargantas. Muchas lecciones de objetos durante un período de tiempo indefinido (perdón por eso). Eventualmente llegará a una masa crítica, convencerá a la (s) persona (s) "correcta" (s).
Su entusiasmo constante y constante & La vocación para TDD es muy importante en una campaña de WHAM.
Debes convertir los cambios de código y las pruebas en momentos de aprendizaje, las lecciones que son importantes para tus codificadores. Hazlo personal. ES DECIR. ¿Se preocupan por una reputación de entregar código limpio por encima del promedio? ¿Se preocupan por la administración que les impone el código que ahora se retrasa porque los probadores de integración les dieron una revisión de la realidad? ¿Jack desea modificar algún código difícil pero teme los efectos secundarios?
Reúna buenos ejemplos de ruptura de pruebas como captura de errores inducidos por el codificador. Los codificadores verán que las pruebas cambiantes son un trabajo innecesario para el código irrelevante. deben entender que las pruebas solo cubrieron sus culos.
Encuentre algún código con implicaciones globales (algún método de utilidad simple), genere algunas pruebas, luego demuestre que las pruebas permiten cambiar sin temor a terremotos en toda la aplicación. Y quiero enfatizar el problema emocional también!
Reúna algunos ejemplos sencillos de código de limpieza (es decir, se pasa a producción) y demuestre que a pesar del esfuerzo adicional para la codificación de prueba , lo hicimos más rápido &erio; Con mayor calidad.
Advertencia: TDD no es una cura para y no puede superar el mal diseño y codificación de OO (pero definitivamente puede exponerlo). No permita que los Luditas culpen al esfuerzo del código de prueba por su incompetencia.
Intentaría de nuevo intentar convencer al gerente. Por lo que has escrito, no creo que puedas convencer a tus compañeros de equipo para hacer TDD a sus espaldas.
Tienes que hablar su idioma. Los gerentes tienden a no sentirse 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 (intentar reproducir el error localmente, jugar con la consola de rieles ...) se ejecutarán las pruebas automáticamente
ahorrará mucho tiempo durante el mantenimiento de la aplicación, cuando puedes detectar errores fácilmente cuando cambias algo. Explique que las pruebas requieren una mayor inversión inicial, pero se pagarán a sí mismas a largo plazo (el mantenimiento de buenas pruebas suele ser rápido y fácil)
y ¿qué vas a hacer con el tiempo extra? crear cosas moar y hacerlos dinero moar :)
En cuanto a los programadores, pruebe este argumento (funcionó para mí desde hace mucho tiempo): "De todos modos, está probando el código, con o sin TDD. Solo lo hace manualmente en lugar de automatizarlo. Los desarrolladores inteligentes se automatizan como muchas cosas como pueden. "
En proyectos reales con fechas límite, las personas desean centrarse en hacer el trabajo con lo que saben. Eso es sólo la naturaleza humana. Y si nunca aprendiste TDD, serías igual que ella en esta situación. Lo guarnatee.
¿Por qué la multitud de recolección de basura no ama, aprende y vive RAII? ¿Cómo podría abogar por la administración automática de la memoria pero aferrarse a la administración antigua para recursos generales como archivos, conexiones, etc.? Debido a que RAII es una tecnología que no conocen, no entienden y no tienen tiempo de usar cuando tienen una fecha límite que requiere trabajo.
Apuesto a que no usas RAII y no estás dispuesto a aprenderlo y entenderlo para tu proyecto actual. Igual que su compañero de trabajo que no está dispuesto a aprender y comprender la TDD.
Lea otras preguntas en las etiquetas tdd communication ruby-on-rails