¿Cómo convenzo a los programadores de mi equipo para que hagan TDD?

Question

Conozco esta pregunta: https://stackoverflow.com/questions/428691/how-to-encourage-implementation-of-tdd

En mi equipo, escribimos muchas pruebas unitarias. Pero, en general, los programadores tienden a escribir pruebas unitarias después de escribir el código. Entonces, primero terminamos la funcionalidad del módulo y luego escribimos las pruebas. Nuestra cobertura es de alrededor del 70% para la mayoría de los módulos. Intenté convencer a mi gerente técnico y a los miembros de mi equipo para que hicieran TDD puro en el que primero escribimos las pruebas y luego el código, pero invadimos. Creo que escribir pruebas primero nos permite descubrir mejor el diseño. ¿Estoy siendo meticuloso, especialmente cuando nuestra cobertura es bastante alta? Si la respuesta a esta pregunta es no, ¿cómo puedo hablar con las personas para que tengan un enfoque de prueba inicial?

EDIT: Creo que escribir pruebas después de escribir el código es una cosa más fácil de hacer. Las personas de mi equipo se han acostumbrado a hacer esto y se oponen a cualquier cambio.

Answer 1

No sé si hay mucho que pueda decirle a personas para convencerlos del valor de TDD. Puede citar lo que los expertos nos han contado al respecto, y sus propias experiencias personales, pero si la gente no está dispuesta a intentarlo, es probable que compartir esta información con ellos sea muy útil.

Mi experiencia con TDD fue básicamente que sonaba como una muy buena idea, pero nunca funcionó de la forma en que se suponía. Entonces, un día lo probé de nuevo en una nueva tarea y terminé con una solución al problema que era más simple de lo que hubiera creído posible, debido enteramente al hecho de que había usado TDD. Creo que cuando los desarrolladores tienen este tipo de experiencia, cambia la forma en que ven las cosas, y los hace más dispuestos a probarlo en otras situaciones.

El desafío es poder demostrar esto a los otros desarrolladores. Una forma en que puedes hacer esto es con el uso de un TDD Kata como this one de Roy Osherove (lo usa en su Curso Máster de TDD). Está diseñado específicamente para demostrar el valor de trabajar en pequeños pasos, implementando solo el código que se necesita para hacer pasar cada prueba. Esto puede mostrarle a la gente cómo funciona el proceso y hacer que se sientan más cómodos con probarlo.

Hubo también un ejercicio de codificación del que escuché que le dio a dos grupos/equipos de desarrolladores una tarea bastante simple, y le pidió a uno de los grupos que usara TDD, y se aseguró de seguir lo más simple que pudiera funcionar "reglas, mientras que el otro equipo hizo las cosas como quisieran. Luego, una vez hecho esto, los equipos cambian de tarea, pero arrojan el código escrito por cada equipo, dejando solo las pruebas. Se supone que los equipos deben recrear el código para la tarea. Normalmente encontrará que el equipo que hereda el código TDD tiene más facilidad para hacerlo.

Teniendo en cuenta todo eso, creo que lo mejor que puede hacer personalmente es comenzar a hacer TDD usted mismo para la mayor parte de su trabajo como sea posible. Esto tiene el potencial de proporcionarle referencias muy específicas sobre dónde y cómo se ha demostrado que TDD es beneficioso en el contexto del proyecto actual. En particular, si realiza revisiones de código, sus pares pueden notar que el código que está escribiendo TDD es más conciso y más fácil de mantener que el código que ha estado escribiendo sin TDD. Su equipo de QA también puede notar una diferencia en la calidad del código, que es una de las cosas que escucha mucho sobre las compañías que se mudan a TDD.

Answer 2

Para ser sincero, debe usar siempre solo use un ciclo de desarrollo/prueba que funcione.

Mucha gente como TDD, y muchos grandes jugadores como Google lo han adoptado; debido a la alta cobertura de prueba.

Sin embargo, parece que usted y su equipo tienden a funcionar bastante bien sin él, y recuerde, y el cambio en el estilo de desarrollo disminuye la productividad al menos temporalmente. Así que recuerda el viejo adagio, no cambies lo que funciona.

Sin embargo, si usted y sus clientes está encontrando que todavía hay una gran cantidad de errores que las pruebas no cubren, TDD es una manera ideal de esa manera-que debe reportar a la gestión que TDD es una forma para aumentar la satisfacción del cliente, así ganar dinero. (¡Eso es lo mejor para usted!)

Answer 3

Un par de sugerencias. Su practicidad puede variar:

• Gane a una o dos personas: su jefe, un interno, etc., antes que a su lado. Su first follower lo hará un líder.
• Programación de pares de inicio o tutoría. Incluso si es solo con un interno o dos, trabajar estrechamente con alguien puede ser una buena manera de influir en su estilo. Si está dispuesto, podría intentar convertirse en gerente.
• Ofrezca una presentación técnica sobre el tema. Haga foco en el por qué y el problema que está resolviendo, en lugar de TDD. Desea que la gente compre el problema en lugar de su solución específica. Incluya otras dos alternativas para que no parezca que solo está tratando de impulsar lo que funciona para usted.
• Obtenga capacitación externa de Object Mentor o similar. Funciona mejor si puedes convencer a tu jefe y el equipo no es un grupo de cínicos sin alma endurecidos.

Answer 4

Quizás Predicar con el ejemplo puede ayudar:

inicio trabajando así mismo

Tal vez crear un tutorial \ script para configurar el entorno (IDE) que no va a agregar una sobrecarga al proceso de TDD:

1. Ejecute las pruebas en una única combinación de teclas
2. la interfaz gráfica de usuario del sistema de prueba debe estar presente en la vista de desarrollo (no sólo en el t vista de vista, para que no tenga que moverse entre ellos)

Supongo que después de un tiempo, la gente tendrá curiosidad y le preguntará si realmente funciona esta TDD, debe tener una respuesta preparada para eso pregunta :-)

Answer 5

¿Se ha encontrado con BDD en absoluto? Hay un cambio asociado en el vocabulario que me parece realmente ayuda a los recién llegados a TDD a recogerlo. Aquí está el cambio de vocabulario:

http://lizkeogh.com/2009/11/06/translating-tdd-to-bdd/

que he encontrado que el uso de este lenguaje ayuda a las personas se centran en por qué es útil escribir las pruebas (o ejemplos) primero. Traduje otro ejemplo en los comentarios.

Incluso entonces, a veces es útil aprender cómo se estructuran las pruebas. Si las personas tienen problemas para aprender a escribirlas primero, escribirlas después es un buen paso de aprendizaje. Tienes razón sobre los beneficios de diseño. Puede tomar un tiempo para grok.

En el pasado, he descubierto que la mejor forma de obtener TDD es tener un entorno seguro para practicar.Tener mi propia aplicación de juguete o correr/asistir a talleres basados ​​en una aplicación de juguete me ayudaron mucho.