Duplicar posible:
How do I convince programmers in my team to do TDD?Cómo inculcar el hábito de TDD en un equipo
Cuáles son algunas de las mejores maneras de fomentar e inculcar el hábito de TDD en un equipo que nunca tiene usado TDD?
¿Alguien puede compartir sus experiencias con la forma correcta e incorrecta de hacer que un equipo use TDD de manera que lo encuentre efectivo y quiera seguir utilizándolo en todos los proyectos futuros?
Esto puede ser simplemente conseguir saliste de la sartén y te metiste en el fuego, pero descubrimos que la mejor manera de convencer a la gente para que adopte TDD es la programación de pares. TDD es una de esas cosas que la mayoría de las personas intelectualmente saben que es efectiva, pero no la aplicarán consistentemente hasta que sientan el beneficio en su intestino. Convencer al instinto de una persona generalmente implica tener a alguien sentado con ellos y realmente hacer TDD durante un tiempo; para algunas personas, esto es en unos pocos días, durante unas pocas semanas, hasta que tengan ese aha. momento en que TDD les ahorra horas de depuración.
Si la gente no quiere hacerlo, tendrá un trabajo difícil convencerlos de los beneficios. Si simplemente no lo saben o no son agnósticos, les recomiendo que discutan con ellos (¿quizás una reunión de equipo de presentación?) Y luego les ofrezcan un par para solucionar algunos errores de esa manera; con suerte, aprenderán el beneficios a través de la experiencia.
En primer lugar, debe asegurarse de que los desarrolladores reciban capacitación sobre cómo realizar un desarrollo basado en pruebas. Después de haber dominado xUnit, deben recibir capacitación sobre cómo emplear objetos simulados. Este es un tipo de TDD más sofisticado (de 'desarrollo' a 'diseño', realmente), y que atrae a los desarrolladores aspirantes, porque al emplear la técnica deben producir un mejor código, además de poder probar mejor las interacciones.
Menciono las ventajas anteriores porque es una forma de tratar de convencer a los equipos para que adopten TDD.
Sin embargo, la verdadera respuesta a esta pregunta es la creación de integración continua, con la opción de código de rechazo que no tiene pruebas de unidad que acompañan :-)
Buena suerte
La configuración de su control de origen para rechazar confirmaciones es * no * la respuesta correcta. La gente responde mal a los estímulos negativos; al crear roadblocks como este, el control de fuente se convierte en un proceso adversarial. Los desarrolladores gastarán enormes cantidades de esfuerzo para subvertir tales procesos, en algunos casos mucho más esfuerzo de lo requerido para simplemente probar TDD. En el mejor de los casos, recomienda escribir pruebas deficientes que satisfagan mínimamente las métricas que utilicen sus requisitos de compromiso. En el peor de los casos, usted convence a más personas de que TDD es una tarea onerosa impuesta por los burócratas y disminuye su motivación para hacer un buen trabajo. –
¿El equipo ya está usando pruebas unitarias regularmente? Si no, esto es más una batalla cuesta arriba. – Mathias