El equipo de principiantes de pruebas unitarias debe realizar una prueba

Estoy trabajando con un nuevo equipo que históricamente no ha realizado NINGUNA prueba de unidad. Mi objetivo es que el equipo eventualmente emplee TDD (Test Driven Development) como su proceso natural. Pero dado que TDD es un cambio mental radical para un equipo de pruebas que no es de unidad, pensé que comenzaría escribiendo pruebas unitarias después de la codificación.

Alguien ha estado en una situación similar? ¿Cuál es una manera efectiva de hacer que un equipo se sienta cómodo con TDD cuando no han hecho ninguna prueba de unidad? ¿Tiene sentido hacer esto en un par de pasos? ¿O deberíamos sumergirnos y enfrentar todos los dolores de crecimiento a la vez?

EDITAR

Solo para aclarar, no hay nadie en el equipo (aparte de mí) que tenga CUALQUIER unidad de exposición / experiencia en pruebas. Y estamos planeando usar la funcionalidad de prueba de unidad integrada en Visual Studio.

Practique sobre errores / defectos existentes.

Esta es una situación realmente difícil. Nunca antes había pasado a TDD de la nada, pero en mi experiencia, lograr que un equipo pase de pruebas sin unidad a escribirlas de manera proactiva ha sido un enfoque muy "paso a paso".

Primero, haga que se sientan cómodos escribiendo pruebas unitarias y sabiendo realmente cuáles son y sus beneficios. Para mis equipos, ha sido mejor escribir pruebas unitarias para errores existentes. Los errores actuales en los sistemas tienen dos cosas que debes enseñar a las personas a escribir bien las pruebas unitarias:

1. una precondición y poscondición esperada
2. un resultado que actualmente no es lo que se espera y viola esa precondición / postcondición

Esto les da a los miembros ejemplos de práctica muy concretos. Pueden escribir una prueba antes de corregir el error, para que falle. Luego, pueden arreglar el código para que pase y corrija el error. Una vez que se sientan cómodos con esto, puede obtenerlos el resto del camino para que puedan escribir pruebas unitarias sin código por adelantado y luego escribir un nuevo código para aprobar sus pruebas.

Creo que el truco es darles algo para que practiquen donde haya un método claro antes y después de las condiciones. Si los requisitos para los métodos son confusos, es difícil incluso para las personas TDD experimentadas saber exactamente por dónde comenzar. Da un paso a la vez y llegarás allí. ¡Buena suerte!

Me las arreglé para convencer a toda mi empresa de cambiar a TDD. No fue fácil, pero valió la pena el esfuerzo: la calidad del código aumentó después de la transición, y ahora nadie imagina volver a los horribles tiempos de codificación de los vaqueros.

1. Explicar, explicar, explicar. No quieres que tu equipo escriba pruebas. Desea que su equipo quiera escribir pruebas. Esto significa que deben comprender completamente por qué deberían hacerlo, cuáles son los beneficios y cómo esto facilitará su trabajo. Rojo, Verde, Refactor , escribir una prueba de regresión como prueba de que se ha solucionado un error, etc. Debe convencerlos de que todo tiene sentido antes de pedirles que escriban cualquier código.

2. Vaya por lo real (primero las pruebas, luego el código). Escribir pruebas después del código apenas tiene sentido, ya que nunca sabrás si realmente funcionan (y la gente escribe casos de prueba con errores). Mi intuición es que la cantidad de esfuerzo que necesita para pasar de ninguna prueba a las pruebas primero es mucho menor de lo que necesita para pasar de ninguna prueba a través del código primero a las pruebas primero , por lo que también puede omitir el paso intermedio.

3. Comience con pruebas de regresión. Estos son bastante simples de entender y brindan gratificación instantánea. Por supuesto, esto supone que el código está bien modularizado y es fácilmente comprobable. Si no, omita este paso.

4. Toma pequeños pasos. TDD tarda un tiempo en acostumbrarse y puede ser frustrante al principio. Intente introducir pruebas en un proyecto o componente nuevo, idealmente: algo no muy importante. Desea evitar a toda costa la situación cuando hay algo realmente importante que hacer muy rápidamente y los programadores sienten que TDD se está interponiendo en el camino.

5. Cuando el equipo comience a sentirse cómodo, tenga todas las nuevas funciones escritas en forma TDD. Esto depende del tamaño de su proyecto, pero después de un tiempo debería obtener una cobertura bastante buena, con solo algunas partes heredadas de su proyecto escritas de la manera anterior.

6. En este punto, el equipo ya debería comprender y adoptar TDD, y las cosas heredadas (no TDD) deberían considerarse difíciles y molestas para trabajar. Obtenlo refactorizado: la mayoría de las personas lo harán con placer.

Algunos otros puntos importantes:

• Asegúrese de estar utilizando el mejor marco de prueba disponible. Será mucho más difícil convencer a las personas de hacer TDD si tienen que interactuar con una biblioteca que está mal escrita.

• Asegúrese de que las pruebas sean fáciles de ejecutar y de que no tome mucho tiempo terminarlas (o hacer trampa, por ejemplo, utilizando un DB en memoria para las pruebas).

• Configure algún software de integración continua, para que las pruebas rotas se encuentren inmediatamente.

Una forma de sentirse cómodo con TDD es escribir primero las pruebas de integración. Introducir costuras de prueba y pruebas de unidades verdaderas más tarde.

El problema con escribir pruebas unitarias después de la codificación es que el código no necesariamente está bien diseñado para ser comprobable . Es posible que necesite refactorizar o rediseñar para introducir las costuras de prueba. Pero, ¿cómo puede refactorizar o rediseñar de manera segura si no tiene cobertura de prueba de ningún tipo?

Las pruebas de integración pueden brindarle esa cobertura inicialmente. Cada vez que tenga una regresión o un problema de producción, corríjalo en el código y cúbralo con una prueba. Una vez que tenga suficientes redes de seguridad proporcionadas por tales pruebas, puede introducir pruebas unitarias de componentes y / o clases aisladas de grano más fino de su sistema.

TDD es muy difícil de implementar y no siempre es la mejor opción para cada equipo de desarrollo. En mi trabajo anterior, el equipo estaba muy concentrado en TDD. Nuestro modelo de desarrollo era completamente TDD utilizando el enfoque de desarrollo ágil. Las pruebas se realizaron mediante pruebas unitarias de Visual Studio.

Si un desarrollador no escribiera ninguna prueba unitaria para su función, estaría en problemas con el líder técnico. Además, si alguien registra una construcción dañada o cualquier prueba unitaria, el desarrollador necesitaría solucionar todos los problemas y agregar $ 1 al bote de dinero del equipo.

Solo una pequeña cosa para agregar, visualice el proceso. Realice la integración continua ejecutando pruebas automáticamente y verifique la cobertura del código. Enumere los módulos probados más completos en alguna página de inicio que todos puedan ver. Eso debería impulsar la competencia por equipos.

Pasé de ninguna experiencia JUnit directamente a TDD, y la experiencia hizo que el valor de TDD fuera inequívocamente evidente. Estoy tan agradecido por las pruebas unitarias que rápidamente me convertí en un evangelista por el enfoque.

He estado en equipos que no hicieron ninguna prueba de unidad, pero se introdujo y se ha vuelto casi común tener algunas pruebas ahora. Sugeriría explorar qué tan bien comprende su equipo los conceptos básicos de las pruebas unitarias, así como qué herramientas desea traer aquí.

En mi caso, traía nUnit para algún código .Net que era una combinación de lógica empresarial, interfaz de usuario y funcionalidad de back-end. Sugeriría ver si hay algunas personas que están más dispuestas a querer llegar a él más que otras para que un par de personas en el equipo lo entiendan y pueda extenderse un poco mejor que la otra cara donde intentas atraer a todos para saltar sobre esto. Al hacer que algunos lo hagan bien primero, esto permite un entrenamiento cruzado para que aquellos que lo recogen puedan probar qué tan bien pueden enseñarlo a otra persona.

Otro punto es considerar traer a aquellos que tienen más experiencia para tratar de mostrar esto hasta cierto punto. Pensé que se introdujo trabajo donde trabajo para mostrarnos algunas cosas que algunas de ellas se adoptaron ampliamente y otras partes no tanto, pero creo que eso sería cierto en la mayoría de los lugares.