¿Cómo lidiar con esas personas que rompen con TDD?

Question

Personalmente, realmente prefiero las pruebas unitarias y las escribo para una "buena" cobertura. (digamos que intento lo más difícil posible para escribir buenas pruebas;)

Como es habitual, algún tiempo después alguien diferente necesita agregar algunas características al código (agregar métodos a las clases, etc.). Él no rompe las pruebas de unidad escrita, pero se niega a escribir adicional (que cubriría las características adicionales del código que escribió). Esto conduce a un gran agujero en el proceso de tdd (y aún peor, tal vez un efecto de ventana rota)

¿Qué puedo hacer para que escriba esas pruebas? ¿cómo lidiar con esas personas?

Answer 1

Recuerde que TDD no se trata principalmente de generar una buena cobertura de prueba de unidad; se trata de motivar buen diseño en primer lugar, para garantizar que el código que escribe haga lo que espera en segundo lugar, y para proporcionar un cuerpo de pruebas de alta calidad en tercer lugar.

Cuando otro programador extiende una clase sin escribir pruebas, se pierden estos beneficios, y usted debe sentir pena por ellos. Pero cuando trabajas, continuarás trabajando de la mejor manera que conozcas (prueba primero) porque sabes que obtienes un código desacoplado que es fácil para el consumidor y que tu código hace lo que esperas.

Lo que más le molesta es que tenga que tener cuidado con lo que refactoriza: si está refabricando el código que se está probando, puede ir rápido y el diseño mejorará rápida y seguramente. Si está refabricando un código que no está probado, debe ser extremadamente cauteloso al refaccionarlo (quizás solo use herramientas automatizadas confiables para hacerlo) o agregar las pruebas.

Al final, continuará beneficiándose de su uso de TDD, ya que producirá un código más claro y correcto, más rápido, mientras que su colega con problemas de TDD sufrirá.

Answer 2

Aparte de la política de la empresa y las repercusiones de su gerente, no hay mucho que pueda hacer al respecto. Quizás haya alguna forma en su herramienta de Control de Fuente de exigir que cualquier cosa pública tenga una prueba unitaria que esté marcada como tal.

Incluso podría escribir una macro que sea parte de su proceso de compilación que busque cualquier elemento marcado PUBLIC (soy un tipo VB), y luego verifique que, en algún lugar de la solución, haya una prueba unitaria con un código comentar que lo vincula suficientemente. Al no tener una prueba de unidad asociada, se rompe la construcción y se envía un correo electrónico a todo el grupo de desarrolladores que avergüenza suficientemente a dicho no-examinador.

Tal vez voy a poner esto en marcha aquí, ahora que lo pienso ...

Answer 3

Si usted tiene un proceso de construcción se puede utilizar una herramienta como NCover o PartCover y fallar la acumulación si la cobertura ISN' t suficiente.

Answer 4

Cobertura del código de seguimiento con alguna herramienta, p. para Java, está Emma, ​​y ​​genera un informe para la gestión con cada lanzamiento. Cuando los números son demasiado bajos o descienden, la gerencia debe investigar las causas.

Answer 5

Par Programación. Con dos personas trabajando en algo, es menos probable que los programadores tomen atajos como este.

Answer 6

Reproduzca el video de "Do not tase me bro!" chico como advertencia

Answer 7

¡No se acerque a esto como un enfrentamiento!Usted está preguntando cómo forzar a un compañero de trabajo a hacer algo que claramente no le beneficia. No puedes hacer que alguien use TDD, como ya te has visto a ti mismo. La única forma en que un desarrollador adoptará TDD es cuando alguien más los ayuda a alcanzar ese "¡ajá!" momento. Sea respetuoso como un colega con otro y muéstrese a través de sus acciones y sea positivo al querer ayudarlo a superar la barrera mental.

Answer 8

Enséñales a tus compañeros de trabajo cómo hacer TDD, para que puedan volcar sus cerebros al revés (tuve esa sensación cuando probé TDD la primera vez) y comenzar a escribir pruebas primero.

Una vez hice un experimento con un programador amigo mío, que no conocía TDD. Llegué a su casa y comenzamos a escribir Tetris usando TDD (pasamos unas 6 horas ese día y progresó muy bien). Primero escribí un método de prueba, y luego él escribió el código para pasar la prueba. Al principio se opuso ligeramente a escribir "lo más simple que podría funcionar" (como codificar los valores de retorno en las primeras pruebas triviales) y no planear mucho más adelante, pero de todos modos lo absorbió y siguió mis instrucciones. A medida que progresábamos, parece que poco a poco comenzó a entender cuál era el punto en todo esto.

Answer 9

Lidere con el ejemplo. Es posible que su compañero de trabajo simplemente no entienda cómo usar TDD de manera adecuada. La próxima vez que suceda, escribe una prueba unitaria para ellos. Asegúrate de señalarles esto: "Oye, noté que agregaste la función x al programa sin una prueba unitaria, así que escribí una para ti y la puse aquí". De esta manera, tienen un ejemplo y no se sentirán avergonzados al tener que preguntar cómo probar la unidad.

Haga esto solo una o dos veces. Después de eso, asegúrese de mencionar cualquier ocurrencia futura. Te sorprendería la diferencia: un educado "Oye, no escribiste una prueba unitaria para la función y, realmente me ayudaría si me escribes uno" hará. Recuerde, su objetivo no es probar haciendo escribir pruebas. Es para hacer que las pruebas de escritura sean menos complicadas que no escribir pruebas.

Si lo anterior no funciona, es hora de una discusión con la administración. Ya ha tratado de resolver la situación de forma amistosa, por lo que es hora de considerar un enfoque menos que amistoso.