programming - Lo más importante para impartir cuando se enseña TDD
tdd wikipedia (12)
El hecho de que sus pruebas lo aprueben no significa que el código sea correcto.
Aparte de eso, diría que es importante considerar probar en su diseño. Si su código es difícil de probar sin un conocimiento profundo de la implementación interna de la unidad bajo prueba, es posible que desee reconsiderar el diseño. De lo contrario, la refactorización se vuelve más propensa a los riesgos porque es probable que las pruebas tengan que cambiarse con el código.
Estoy colaborando con un grupo de profesionales para organizar un evento que ayude a enseñar la práctica de TDD a las personas que están interesadas, pero que no tienen experiencia (novicios).
Estamos tratando de crear laboratorios, talleres, etc. y estoy tratando de pensar en la cosa más importante que debemos impartir a estos individuos para ayudarlos a tener éxito en la práctica de TDD en el futuro.
¿Qué dirías que deberíamos dar prioridad al aprendizaje? ¿Qué aspecto de la enseñanza de TDD es el más importante? Si tienes que hacer dos cosas, está bien, no te retendré en la parte ÚNICA :)
En mi experiencia, usar TDD me permite a mí y a mi equipo refactorizar sin piedad nuestro código sin preocuparnos de que rompa algo inesperado.
Así que supongo que para mí el aspecto más importante de TDD es la cobertura, ya que una buena cobertura me da la confianza para refactorizar cada vez que veo un lugar en la base de código que puede usarlo.
Haga hincapié en diferentes tipos de pruebas. Tanto las pruebas de caja negra como las pruebas de caja blanca son importantes y tienen diferentes propósitos. Las pruebas de caja blanca no están ahí para verificar la corrección porque no pueden probar el sistema en general. Está ahí para hacer que los olores de código sean aún más desagradables y, por lo tanto, proporcionar una mejor dirección de refactorización. La prueba de caja negra está ahí para probar la corrección. Cada característica debe ser probada en caja negra.
Además, enfatice las diferencias en la cobertura de la prueba. Debido a los problemas combinatorios y de repetibilidad, es imposible hacer una prueba de cuadro negro en cada ruta de código en su aplicación. Mi regla es que una característica no está completa hasta que se prueba la caja negra. Deberías ayudar a los estudiantes a descubrir sus propias reglas. Sin embargo, las pruebas de caja blanca no deben tener dependencias de clases externas; por lo tanto, cada línea de cada clase debe ser probada en caja blanca.
No omita pasos en el proceso. Lleva más tiempo entrar en el groove inicial de TDD, pero una vez que está en su lugar, todo el SDLC es más rápido y está mucho más libre de errores.
Rojo - Verde - Refactor -> simplemente hazlo.
No sé si esto podría contar como la cosa más importante, pero fue algo que me llevó un tiempo "obtener" cuando estaba explorando por primera vez el uso de TDD.
No escriba el código en su cabeza antes de escribir la prueba.
Cuando comencé a hacer TDD, "sabía" cuál debería ser el diseño. Yo "sabía" qué código quería escribir. Entonces escribí una prueba que me permitiría escribir ese fragmento de código.
Cuando estaba haciendo esto, no estaba realmente haciendo TDD, ya que estaba escribiendo el código primero (incluso si el código solo estaba en mi cabeza :-)
Me tomó algo de tiempo (y algo de astucia por gente inteligente) darme cuenta de que necesita centrarse en la prueba. Escriba la prueba del comportamiento que desea, luego escriba el código mínimo necesario para que pase, y luego permita que el diseño surja a través de la refactorización. Repita hasta que termine.
Proceda en pasos de bebé.
Asegúrese de que sus pruebas solo cubran un alcance muy pequeño y, como PhlipCPP dice: '' Realice la EDICIÓN MÍNIMA necesaria para que la prueba pase. ''
Aun así, hay mucho para TDD, por lo que aún debe asegurarse de no perderse nada.
Sugiero: "Sé paciente". Se siente extraño al principio. Para mí, probablemente fueron tres proyectos antes de que comenzara a sentirse natural.
Tratando con la presión de abandonar TDD cuando las fechas límite son cada vez más ajustadas. Este es uno de los mayores problemas que he recibido para ayudar a personas y equipos con TDD. Han tenido problemas para expresar la importancia y el valor de dejar caer destacado en lugar de las pruebas a la gestión superior.
TDD, en mi opinión, es todo sobre el ritmo (rojo, verde, refactor). Bajar el ritmo lo lleva a superar la "joroba" de "no entenderlo". Y si no baja el ritmo, probablemente no se quede con TDD por mucho tiempo. La esencia del ritmo es pasos de bebé, que ya se ha mencionado. Escribe el menor código posible y refactoriza sin piedad.
Una cosa para enfatizar es que TDD intercambia algunas ganancias a corto plazo para las de largo plazo. Comenzar con TDD reducirá invariablemente su productividad. Pero una vez que aprendes el ritmo, es como entrar en un ritmo, y realmente puede ayudarte a trabajar más rápido. Por no mencionar el efecto secundario de TDD es una base cada vez mayor de pruebas unitarias que proporcionan pruebas de regresión. Una consecuencia inevitable del software es que los sistemas que se mantienen (sin un conjunto de pruebas de regresión automatizadas) se degradan con el tiempo.
Haga hincapié en que TDD es un cambio de paradigma para desarrolladores . Si está formando un nuevo equipo, tenga en cuenta que tomará hasta seis meses lograr que el equipo sea totalmente efectivo como practicantes de TDD. Una vez que tengas un equipo ágil y maduro que practique efectivamente TDD, el emparejamiento le permitirá a un nuevo desarrollador entrar al swing unas pocas cosas después de un par de iteraciones. Además, al usar pares de un equipo para sembrar una nueva línea, puedes obtener la nueva línea para acelerar en TDD mucho más rápido que la primera línea.
En los proyectos que hemos medido, hemos visto una caída de seis veces en los defectos encontrados durante la prueba de regresión funcional / regresiva una vez que el equipo aprendió a hacer TDD. Eso es un ahorro significativo. Además, el código refleja un diseño más limpio, con menos líneas de código para cada característica. TDD, pero una parada virtual para chapado en oro. TDD es más efectivo si tus cartas tienen criterios de aceptación.
TDD también permite un ritmo sostenible. El equipo encontrará que pueden seguir obteniendo el mismo número de funciones con cada iteración porque el código permanece limpio con pocos defectos. Con TDD y la prueba de regresión / función automática, a menudo vemos cero defectos encontrados durante la Prueba de aceptación del usuario.
Estoy de acuerdo con lo que dijo Jon en su respuesta , pero creo que un corolario importante es que la capacidad de prueba no dicta "buen diseño" , sino que es solo un indicador de que su diseño está dentro del objetivo.
Se trata de diseño . NO se trata de las pruebas.