TDD frente de la Unidad de pruebas [cerrado]

Todavía vale la pena escribir las pruebas unitarias después de escribir el código. Es solo que a veces a menudo es más difícil porque su código no fue diseñado para ser comprobable, y es posible que lo haya complicado en exceso.

Creo que una buena forma pragmática de incorporar un equipo al TDD es proporcionar el método alternativo de "prueba durante el desarrollo" en el período de transición, o posiblemente a largo plazo. Se les debe alentar a tomar secciones de código TDD que les parezcan naturales. Sin embargo, en secciones de código que parecen difíciles de abordar primero en pruebas o cuando se utilizan objetos predeterminados por un proceso de A&D no ágil, los desarrolladores pueden tener la opción de escribir una pequeña sección del código, luego escribir pruebas para cubrir ese código y repetir este proceso. Escribir pruebas unitarias para algún código inmediatamente después de escribir ese código es mejor que no escribir ninguna prueba unitaria en absoluto.

En mi humilde opinión, es mejor tener una cobertura de prueba del 50% con "code first, test after" y una biblioteca completada al 100%, que una cobertura de prueba del 100% y una biblioteca completada al 50% con TDD. Después de un tiempo, es de esperar que sus compañeros desarrolladores encuentren entretenido y educativo escribir pruebas para todo el código public que escriben, por lo que TDD se abrirá paso a escondidas en su rutina de desarrollo.

Acabo de leer esto en un calendario: "Cada regla, ejecutada al máximo, se vuelve ridícula o incluso peligrosa."Así que mi sugerencia es no ser religioso al respecto. Cada miembro de su equipo debe encontrar un equilibrio entre lo que se siente "correcto" cuando se trata de pruebas. De esta manera, cada miembro de su equipo será más productivo (en lugar de, por ejemplo, pensar "¿por qué tengo que escribir esta prueba de sti****??").

Así que algunas pruebas son mejores que ninguna, las pruebas después del código son mejores que pocas pruebas y probar antes del código es mejor que después. Pero cada paso tiene sus propios méritos y no debes fruncir el ceño ni siquiera con los pasos pequeños.

TDD es sobre diseño! Por lo tanto, si lo usa, estará seguro de tener un diseño comprobable de su código, lo que facilita la escritura de sus pruebas. Si escribes pruebas después de escribir el código, son todavía valiosas pero en mi humilde opinión estarás perdiendo el tiempo ya que probablemente no tendrás un diseño comprobable.

Una sugerencia que puedo darle para tratar de convencer a su equipo de adoptar TDD es el uso de algunas de las técnicas descritas en Mary Linn y Linda Rising book: Patrones para Introducción de nuevas Ideas

Si son nuevos en las pruebas que IMO comenzar código de prueba que ya ha sido escrito y poco a poco pasar a escribir pruebas primero. Como alguien tratando de aprender TDD y nuevo en las pruebas unitarias, he encontrado un poco difícil hacer un 180 completo y cambiar mi mentalidad para escribir pruebas antes del código, por lo que el enfoque que estoy tomando es una especie de mezcla 50-50; cuando sé exactamente cómo se verá el código, escribiré el código y luego escribiré una prueba para verificarlo. Para situaciones en las que no estoy del todo seguro Voy a empezar con una prueba y trabajar mi camino hacia atrás.

También recuerde que no hay nada malo en escribir pruebas para verificar el código, en lugar de escribir código para satisfacer las pruebas. Si tu equipo no quiere seguir la ruta TDD, entonces no los fuerces.

Probablemente pueda lograr que el equipo escriba pruebas unitarias una vez que el código esté escrito (tal vez como un requisito para verificar el código) y mi suposición es que todavía hay valor en escribir esas pruebas unitarias.

No hay absolutamente ninguna duda sobre el hecho de que hay valor en el código probado por unidad (independientemente de cuándo se escribieron las pruebas) e incluyo "el código está probado por unidad" en la "Definición de Hecho". Las personas pueden usar TDD o no, siempre y cuando prueba.

Con respecto al control de versiones, me gusta usar " ramas de desarrollo" con una política probada por unidad (es decir, el código compila y construye, todas las pruebas unitarias pasan). Cuando las características se realizan, se publican desde las ramas de desarrollo al tronco. En otras palabras, la rama del tronco es la "Rama hecha " (¡No hay basura en el tronco!) y tiene una política shippable (puede publicarse en cualquier momento) que es más estricta e incluye más cosas que "unit tested".

Esto es algo con lo que tu equipo tendrá que tener sus propios éxitos antes de empezar a creerlo. Voy a despotricar sobre mi epifanía NUnit para cualquiera que se preocupa:

Hace unos 5 años descubrí NUnit cuando trabajaba en un proyecto. Casi habíamos completado V1.0 y creé algunas pruebas solo para probar esta nueva herramienta. Tuvimos un montón de errores (obviamente! porque éramos un equipo nuevo, con un plazo ajustado, altas expectativas (¿suena familiar?) sucesivamente. De todos modos tenemos 1.0 y comenzar 1.1. Reorganizamos un poco el equipo y me asignaron 2 desarrolladores. Hice una demostración de 1 hora para ellos y les dije que todo lo que escribíamos tenía que tener un caso de prueba con él. Estuvimos constantemente "detrás" del resto del equipo durante el ciclo de desarrollo 1.1 porque estábamos escribiendo más código, las pruebas unitarias. Terminamos trabajando más, pero aquí está la recompensa when cuando finalmente entramos en pruebas teníamos exactamente 0 errores en nuestro código. Ayudamos a todos los demás a depurar y reparar sus errores. En la autopsia, cuando el conteo de bichos apareció, llamó la atención de TODOS.

No soy lo suficientemente tonto como para pensar que puedes probar tu camino hacia el éxito, pero soy un verdadero creyente cuando se trata de pruebas unitarias. El proyecto adoptó NUnit y pronto se extendió a la empresa para todos los proyectos. Net como resultado de 1 éxito. El período de tiempo total para nuestro lanzamiento V1.1 fue de 9 semanas de desarrollo, por lo que definitivamente NO fue un éxito de la noche a la mañana. Pero a largo plazo, resultó exitoso para nuestro proyecto y la compañía para la que construimos soluciones.

No hay duda de que las pruebas (Primero, Mientras o incluso Después) salvarán su tocino, y mejorarán su productividad y confianza. ¡Recomiendo adoptarlo!

Estaba en una situación similar, porque era un desarrollador "novato", a menudo me frustraba cuando trabajaba en el proyecto del equipo por el hecho de que una contribución había roto la compilación. No sabía si yo tenía la culpa o incluso en algunos casos, a quién culpar. Pero yo estaba más preocupado de que yo estaba haciendo lo mismo a mis compañeros desarrolladores. Este la realización motivó entonces a adoptar algunas estrategias de TDD. Nuestro equipo comenzó a tener juegos tontos y reglas, como que no puedes ir a casa hasta que pasen todas tus pruebas, o si envías algo sin una prueba, entonces tienes que comprar a todos "cerveza / almuerzo / etc" y eso hizo que TDD fuera más divertido.

Uno de los aspectos más útiles de las pruebas unitarias es garantizar la corrección continua del código que ya funciona. Cuando pueda refactorizar a voluntad, deje que un IDE le recuerde los errores de tiempo de compilación, y luego haga clic en un botón para que sus pruebas detecten cualquier error potencial de tiempo de ejecución sometimes a veces llegando a bloques de código previamente triviales, entonces creo que encontrará que su equipo comienza a apreciar TDD. Así que comenzar con probar el código existente es definitivamente útil.

También, para ser franco, tengo aprendí más sobre cómo escribir código comprobable al intentar probar el código escrito que al comenzar con TDD. Puede ser demasiado abstracto al principio si está tratando de pensar en contratos que logren el objetivo final y permitan las pruebas. Pero cuando nos fijamos en el código y puede decir "Este singleton aquí estropea completamente la inyección de dependencia y hace que las pruebas de esto sea imposible," usted comienza a desarrollar una apreciación de lo que los patrones hacen su vida de prueba más fácil.

Bueno, si no escribes tests primero no es "Test Driven", es solo testing. Tiene beneficios en sí mismo y si ya tiene una base de código agregando pruebas para ello es ciertamente útil incluso si no es TDD sino simplemente probando.

Escribir pruebas primero se trata de enfocarse en lo que el código debe hacer antes de escribirlo. Sí, también te haces una prueba haciendo eso y es bueno, pero algunos pueden argumentar que ni siquiera es el punto más importante.

Lo que haría es entrenar al equipo en juguete proyectos como estos (ver Coding Dojo, Katas) usando TDD (si puedes conseguir programadores TDD experimentados para participar en dicho taller sería aún mejor). Cuando vean los beneficios, usarán TDD para el proyecto real. Pero mientras tanto no los obliguen, si no ven el beneficio no lo harán bien.

Si tiene sesiones de diseño antes de escribir código o tiene que producir un documento de diseño, entonces podría agregar Pruebas unitarias como el resultado tangible de una sesión.

Esto podría servir como una especificación sobre cómo debería funcionar su código. Fomente el emparejamiento en la sesión de diseño, para que la gente hable sobre cómo debería funcionar algo y qué debería hacer en determinados escenarios. Cuáles son los casos de borde, con casos de prueba explícitos para ellos para que todos sepan lo que va a hacer si se le da un null argumento, por ejemplo.

Un aparte pero BDD también puede ser de interés

Puede encontrar algo de tracción al mostrar un ejemplo o dos donde TDD resulta en menos código que se escribe - debido a que solo se escribe el código requerido para hacer que la prueba pase, la tentación de la placa de oro o participar en YAGNI es más fácil de resistir. El código que no escribes no necesita ser mantenido, refactorizado, etc., por lo que es un "ahorro real" que puede ayudar a vender el concepto de TDD.

Si puede demostrar claramente el valor en términos de tiempo, costo, código y errores guardados, puede encontrar que es más fácil vender.

Comenzar a construir clases de prueba JUnit es la manera de comenzar, para el código existente es la única manera de comenzar. En mi experiencia es muy útil crear clases de prueba para el código existente. Si la administración piensa que esto invertirá demasiado tiempo, puede proponer escribir solo clases de prueba cuando se encuentre que la clase correspondiente contiene un error o necesita limpieza.

Para el proceso de mantenimiento, el enfoque para que el equipo pase la línea sería escribir pruebas JUnit para reproducir errores antes de arreglarlos, es decir,

• se informa de error
• cree una clase de prueba JUnit si es necesario
• añadir una prueba que reproduzca el bug
• arregla tu código
• ejecute la prueba para mostrar que el código actual no reproduce el error

Puede explicar que al "documentar" los errores de esta manera evitará que esos errores vuelvan a aparecer más tarde. Ese es un beneficio que el equipo puede experimentar inmediatamente.

He hecho esto en muchas organizaciones y he encontrado la mejor manera de iniciar y seguir TDD es configurar la programación de pares. Si tienes a alguien más con quien puedes contar que conoce TDD, entonces los dos pueden dividirse y emparejarse con otros desarrolladores para hacer programación emparejada usando TDD. Si no, entrenaría a alguien que te ayudará a hacer esto antes de presentarlo al resto del equipo.

Uno de los principales obstáculos con las pruebas unitarias y especialmente TDD es que los desarrolladores no saben cómo hacerlo, por lo que no pueden ver cómo puede valer la pena su tiempo. Además, cuando comienza por primera vez, es mucho más lento y no parece proporcionar beneficios. Solo realmente te está proporcionando beneficios cuando eres bueno en ello. Al configurar sesiones de programación emparejadas, puede hacer que los desarrolladores puedan aprenderlo rápidamente y ser buenos en él más rápido. Además, serán capaces de ver los beneficios inmediatos de ella a medida que trabajan, aunque juntos.

Esto el enfoque ha funcionado muchas veces para mí en el pasado.

Una forma poderosa de descubrir los beneficios del TDD es reescribir de forma significativa algunas funcionalidades existentes, quizás por razones de rendimiento. Al crear un conjunto de pruebas que hacen un buen trabajo cubriendo toda la funcionalidad del código existente, esto le da la confianza para refactorizar al contenido de su corazón con plena confianza de que sus cambios son seguros.

Tenga en cuenta que en este caso estoy hablando de probar las pruebas de diseño o de unidad de contrato que prueban la implementación los detalles no serán adecuados aquí. Pero, de nuevo, TDD no puede probar la implementación por definición, ya que se supone que deben escribirse antes de la implementación.

TDD es una herramienta que los desarrolladores pueden utilizar para producir mejor código. Resulta que siento que el ejercicio de escribir código comprobable es tan valioso como las pruebas en sí. Aislar la IUT (Implementación bajo prueba) para fines de prueba tiene el efecto secundario de desacoplar su código.

El TDD no es para todos, y no hay magia que haga que un equipo elija hacerlo. El riesgo es que los escritores de pruebas unitarias que no saben lo que vale la pena probar escribirán muchas pruebas de bajo valor, que será carne de cañón para los escépticos del TDD en su organización.

Normalmente hago pruebas de aceptación automatizadas no negociables, pero permitir que los desarrolladores adopten TDD como les convenga. Tengo mis TDDers experimentados entrenan / mentor al resto y" prueban " la utilidad con el ejemplo durante un período de muchos meses.

Esto es tanto un cambio social/cultural como un cambio técnico.