¿Cómo motivar a los compañeros de trabajo a escribir pruebas unitarias? [cerrado]

Me di cuenta de que hablar de TDD apenas funciona. A la gente le gusta ver resultados brutos . Decir que "las pruebas de escritura reducirán el tiempo de desarrollo" es probablemente cierto, pero puede que no sea suficiente para que nadie se convenza.

Estaba en una posición similar (bueno, no tan mala como la tuya), y se resolvió cuando la gente comenzó a trabajar en mi código (nota: mi código fue probado en la unidad, otros no tanto). Cuando algo dejó de funcionar, el seguimiento natural después de la investigación local fue preguntarme cuál podría ser la razón . Luego nos sentamos, hicimos pruebas de unidad y vimos lo que pasó. Si las pruebas pasaban, la mayoría de los problemas de tiempo estaban en el código nuevo, no probado. De lo contrario, las pruebas generalmente podían detectar el problema (o al menos apuntarnos en la dirección correcta). Arreglamos el error, las pruebas volvieron a funcionar, todos estaban felices.

En pocas palabras, algunas situaciones como esta sucedieron y 2 desarrolladores más se convirtieron en entusiastas de TDD / testing (todavía quedan algunas más, pero parece prometedor).

En cuanto al consejo, puedes probar con kata TDD; tarea sencilla de implementar utilizando un enfoque de prueba primero en lugar de sin pruebas . Dependiendo de la complejidad de la tarea, el enfoque de no prueba generalmente debe ser más lento, especialmente con los cambios requeridos incrementales:

• calculadora de cadenas de Roy
• OCR del banco

Editar : el comentario de OP me hizo darme cuenta de que hay un argumento aún más sólido a su disposición: regresión , también conocido como errores de respuesta . Ese tipo de situaciones son ejemplos perfectos que demuestran cómo pueden ser las pruebas unitarias beneficiosas. A la gente le gustan los números, como dije, decir que "la prueba de unidad es buena" podría no ser convincente, pero organizar datos como los siguientes podría ser:

• el tiempo dedicado a implementar la función (no se escribieron pruebas; supongo que esto sucedió a menudo, por lo que debería ser relativamente fácil encontrar ese ejemplo)
• tiempo estimado para implementar la función con TDD (o incluso pruebas después de enfoque; no importa; lo importante es la presencia de pruebas unitarias)
• el tiempo dedicado a resolver el error en código probado y no probado

Una cosa sobre la que te advierto (esto puede ser obvio, pero vale la pena mencionar): sesgo de resultados : asegúrate de que no seleccione un ejemplo en el que la única manera de detectar errores con la prueba fuera escribir la prueba para ese error. Por lo general, nadie sabe que se producirán errores por adelantado, pero es tentador decir "hombre, este error sería trivial si tuviéramos la prueba de X" : es fácil encontrar una táctica ganadora para una guerra después de que haya terminado. .

El resultado de esos ejemplos debería ser una pregunta simple: si pudiera pasar x-hours desarrollando la función Y, ¿por qué insistiría en hacerlo en 2x ?

Primero debes saber por qué no están escribiendo pruebas.

Los horarios ajustados de desarrollo son a menudo la razón, pero dices que no tienes eso.

La siguiente razón es que con una gran base de código no probada existente, las pruebas de escritura probablemente parecen abrumadoras, un trabajo sin fin (como lavandería y casi tan emocionante). Entonces, la naturaleza humana es pensar que es demasiado para enfrentar, así que lo omitiré.

Otra razón podría ser que si bien piensan que las pruebas son una buena idea, no están seguras de cómo comenzar a escribirlas, especialmente si nunca han trabajado en ningún lugar que las haya escrito.

Otra posibilidad importante es que realmente no ven ningún valor para más trabajo, a pesar de que están prestando atención a la idea.

Entonces, ¿cómo manejas las diferentes razones?

La razón uno es simple, muestre un ejemplo de cómo ahorra tiempo de desarrollo.

Razón dos: muéstrales cuántas pruebas has escrito en un año y qué porcentaje de la base de código cubre. Haz los cálculos para mostrar cuántas pruebas más podrían tener en este momento el año que viene si hacen esto. Una vez que ven que los pequeños fragmentos de progreso a diario se acumulan, la idea no es tan abrumadora. Si puede extraer los datos del sistema, muéstreles cuántos errores fueron errores repetidos en las partes no comprobadas del código y cuántos errores repetidos aparecen en el código con pruebas unitarias.

La razón 3 es entrenamiento, no solo demostración. Haz que escriban pruebas en una clase de entrenamiento.

Razón 4, este es el quid de la cuestión. Primero, elija un punto de dolor, uno de esos errores que ha regresado varias veces. Cuando eso ocurra, este es el momento de sugerir a la gerencia que si tuvieran pruebas de unidad en este artículo, no volvería como un centavo malo.

Otra forma de abordar la razón 4 es hacer que la administración forme parte del proceso y el código no pase la revisión del código a menos que las pruebas también pasen la revisión del código. Es mejor acercarse a ellos y convertir esto en una política justo después de uno de esos puntos problemáticos o, preferiblemente, justo después de haber tenido varios en cuestión de días.

A todos nos gusta pensar que como desarrolladores nos autogestionamos (LOL), pero a los ambiciosos les importará lo que la administración les haga hincapié en que deberían preocuparse y los profesionales que realmente se autogestionan ya están escribiendo las pruebas. Si a ellos no les importa ser profesionales y hacer las mejores prácticas porque mejoran el producto o les importa cómo impresionar a los gerentes para que sean promovidos (o no despedidos), entonces puede considerar si este es el lugar adecuado para usted. Si no puede lograr que la administración se preocupe por las mejores prácticas, entonces estará librando una batalla cuesta arriba en todo momento, y podría evaluar si esta es la cultura corporativa adecuada para usted. Si bien cada lugar de trabajo tiene sus problemas (y escapar no siempre es la respuesta), este lugar no parece ajustarse a su nivel de profesionalismo.

Comenzaría demostrando los beneficios de TDD. Trate de mostrar los beneficios de las pruebas unitarias.

Como seres humanos normales, los desarrolladores están motivados por los beneficios. No quieren hacer cosas que solo crean más trabajo. La prueba de unidad significa menos trabajo . Significa salir con amigos más. Significa divertirse más porque no tienes que pasar todas las noches programando hasta las 11 pm. Significa ir de vacaciones más con tranquilidad.

Uno de los mayores beneficios de TDD es que puede refactorizar su programa para un mejor diseño o simplemente cambiar el nombre de algo ... y siempre que el diseño no rompa las pruebas , puede tener 100% de confianza en que su cambio no rompió nada.

Otro gran caso para TDD es crear pruebas unitarias para código heredado . Esto representaría una de las mejores maneras de comenzar a refactorizar el mal. A largo plazo, esto servirá para mejorar su conocimiento del código base, comprender sus fortalezas y fallas, detectar la lógica de negocios codificada en el código y darle un buen comienzo para mejorar la calidad.

Buenas referencias para leer más:

• Por qué debería escribir pruebas unitarias
• Visibilidad de la motivación y pruebas unitarias
• El El arte de las pruebas unitarias, según Roy Osherove

enlace

Creo que marqué ese enlace de un artículo de Jeff Atwood hace algún tiempo [edit: sip, aquí está] . Viejo pero relevante. ¡Debido a estos beneficios y otros que, sin duda, se detallarán en otras respuestas, sus programadores deberían poder motivarse a sí mismos ! Les permitirá trabajar de manera más eficiente y, por lo tanto, facilitarán un poco su trabajo. ¿Quién no quiere eso?

En lo que respecta a su segunda pregunta: su sentido de pertenencia y orgullo por los estándares de calidad de su código deben hacer que continúe con ellos . Piense en lo que quiere lograr al tener dichos estándares y quién se beneficia de ellos. Mis estándares de código personal también pueden ser frustrantes, pero siempre siento que estoy haciendo un favor al mundo / empresa / equipo implementándolos. Así que no creo que estés tratando de hacer demasiado, los resultados varían de un lugar a otro, pero al menos estás haciendo el esfuerzo.

Esto parece ser un gran caso de ejemplo de ejemplo .

Hay dos aspectos inherentes de la naturaleza humana contra los que estás luchando:

• A los creativos no les gusta el proceso.
• A la mayoría de las personas no les gustan los juicios negativos externos sobre su calidad.

Es muy difícil combatir esto con conferencias, declaraciones de gestión o incluso con lógica. Tienes que ganar aprovechando un aspecto alternativo de la naturaleza humana.

• La gente imita el comportamiento de los mejores empleados

Si los mejores empleados usan TDD y funciona, el proceso se expandirá. Si no lo hacen, no lo hará. Si necesita convencer a alguien, es el primer o el segundo empleado.

Pregúnteles.

Dice que se les ha dicho a las personas y está de acuerdo en que deben escribir más pruebas. ¿Por qué no lo son?

Puede que no sea (a menudo no es) una cuestión de simple motivación. Podrían olvidarse de ellos. Pueden sentirse bajo la presión del tiempo. Es posible que no sepan cómo escribir buenas pruebas. Podrían pensar que eres tan bueno que no necesitan hacerlo. Conocer la causa raíz te ayudará a resolver mejor el problema.

Usted pensaría que las pruebas unitarias serían las ventas por sí mismas. No sé cómo funciona su empresa, pero cuando hay un problema durante una implementación de producción, trabajamos hasta que se soluciona. No importa si sucede a las 2 de la mañana de un domingo por la mañana. Esto es muy raro para nosotros, pero cuando lo hace, apesta.

Comenzaría preguntándoles cuántas veces tuvieron que levantarse en medio de la noche para solucionar un problema importante que podría haberse encontrado fácilmente en las pruebas automatizadas. Esto no quiere decir que las pruebas automáticas lo solucionen todo, pero debería ayudar a reducir eso.

El segundo gran vendedor es el ciclo de control de calidad. Antes del inicio de TDD en mi empresa, impulsábamos los nuevos lanzamientos a QA para probarlos cada semana. Ellos crearían un montón de errores a partir de ese lanzamiento, nosotros arreglamos esos errores y presionamos otro lanzamiento. Repetir hasta terminar. El primer proyecto que hicimos en TDD no requirió un empuje hacia el control de calidad hasta varias semanas después. Y el número de errores encontrados ha sido muy, muy pequeño. 10% en comparación con un proyecto similar. ¿De todos modos tienes que compilar esas estadísticas para tu equipo?

El otro gran punto de venta fue cómo se adoptó el código después de que se adoptó el TDD, fue más fácil de leer, porque queríamos facilitar la prueba. Muestra una comparación entre el código escrito para las pruebas unitarias y el código no escrito.

Finalmente, muéstrales cómo podrán refactorizar el código con confianza.

Tenga todo eso en cuenta cuando no tenga ganas de escribir exámenes. :)

Me gustaría ampliar la respuesta de HLGEM , especialmente esta sección:

  

La siguiente razón es que con una gran base de código no probada existente, las pruebas de escritura probablemente parecen abrumadoras, un trabajo sin fin (como lavandería y casi tan emocionante). Entonces, la naturaleza humana es pensar que es demasiado para enfrentar, así que lo omitiré.

Descubrí que el código que escribo con la intención de escribir pruebas es significativamente mejor que el código que escribo sin la intención de escribir pruebas; preguntándome ¿Cómo probaré esta función? obliga a un mejor diseño de todas y cada una de las funciones. (Menos confianza en los datos globales o semi-globales; IO separado del cómputo; las funciones hacen solo una cosa; manejo consistente de errores; etc.)

Tratar de poner las pruebas en el código antiguo que no se escribió teniendo en cuenta las pruebas puede ser más que frustrante.

He usado algunas técnicas:

a) configurar una compilación automatizada. Cuando alguien rompe algo que probaste, muéstrale cómo lo detectó la prueba y cuán malo hubiera sido el error.

b) Realiza proyectos complejos con pruebas (conduces). Esto mostrará cómo pocos errores existen en ese proyecto. Tuve un proyecto complejo de interacción con el servidor que comenzó a funcionar perfectamente. Nunca falló el control de calidad y todas las pruebas de integración se realizaron sin problemas. Ese sistema llegó a ser conocido como altamente estable y la administración en general estaba contenta con él. Lo que haces en estas situaciones es cómo las pruebas unitarias lo habilitan.

c) Tire de una persona a la vez. El que te escucha. Enfréntate a los errores y muestra cómo las pruebas exponen problemas profundos y difíciles. Esto ayuda. Nunca es una cosa fácil. Pero una vez que tengas un fan, él solo te ayudará. Es un efecto dominó.

Prueba de unidad de horneado en el proceso. Si se muestra un error en la producción que es demasiado obvio para atraparlo en la prueba de unidad, entonces este tipo se responsabiliza. Asigna personas para que escriban cada prueba que hagan. Escoja los casos al azar y observe la ejecución de algunos casos cada semana. Al realizar pruebas unitarias, las personas preguntarán acerca de los requisitos y, eventualmente, vincularán los requisitos con el desarrollo y, con suerte, desarrollarán el software que tanto requiere como funciona :)