Lo más importante para impartir al enseñar TDD

Question

Estoy colaborando con un grupo de profesionales para organizar un evento que ayude a enseñar la práctica de TDD a personas 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 ayudarles a tener éxito en la práctica de TDD en el futuro.

¿Qué dirías que deberíamos hacer de nuestra prioridad para el aprendizaje? Qué aspecto de la enseñanza de TDD es el más importante. Si tiene que hacer dos cosas, está bien, no lo retendré en la parte ÚNICA :)

Answer 1

It's about design. Es NOT sobre las pruebas.

Answer 2

No saltee 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 - Refactorio -> just do it.

Answer 3

En mi experiencia, el uso de TDD nos permite a mí y a mi equipo refactorizar sin piedad nuestro código sin preocuparnos de que rompa algo inesperado.

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.

Answer 4

El hecho de que sus pruebas lo aprueben no significa que el código sea correcto.

Aparte de eso, yo 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.

Answer 5

Sugiero, "Sé paciente". Se siente extraño al principio. Para mí, probablemente fueron tres proyectos antes de que comenzara a sentirse natural.

Answer 6

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.

Answer 7

Proceda en pasos de bebé.

Asegúrese de que sus pruebas solo cubran un alcance muy pequeño y, como dice PhlipCPP: 'Realice la EDICIÓN MÍNIMA necesaria para hacer la prueba. '

Aún así, hay mucho para TDD, por lo que aún debe asegurarse de no perderse nada.

Answer 8

Enfatizar 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 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.

Answer 9

estoy de acuerdo con lo Jon said in his answer, pero creo que un corolario importante es que la capacidad de prueba no dicta "buen diseño", pero es sólo un indicador de que su diseño en el blanco.

Answer 10

No sé si esto contaría como la cosa más importante - pero era algo que me tomó un tiempo para "obtener" cuando estaba explorando primero usando TDD.

No escriba el código en su cabeza antes de escribir la prueba.

Cuando empecé a hacer TDD "sabía" lo que 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 yo estaba haciendo esto en realidad no estaba haciendo TDD - ya estaba escribiendo el código en primer lugar (incluso si el código era sólo en mi cabeza :-)

Me tomó algún tiempo (y algunos hurgando por gente inteligente) para darse 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.

Answer 11

TDD, en mi mente, tiene que ver con 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.

Answer 12

Enfatizar que TDD es un cambio de paradigma para el desarrollador s. 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 funcionamiento/de regresión automatizado 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 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.