Entiendo el desarrollo basado en pruebas hasta ahora, que solo se le permite escribir código productivo cuando tiene una prueba unitaria (roja) que falla.
No. Solo se le permite escribir el código más simple posible para cambiar el mensaje de la prueba. No dice nada sobre qué tipo de prueba.
De hecho, probablemente comenzará escribiendo una prueba de aceptación fallida (roja) para un criterio de aceptación, más precisamente, escriba la prueba de aceptación más simple que podría fallar; luego ejecuta la prueba, observa cómo falla y verifica que falla por la razón correcta. Luego, escribe una prueba funcional fallida para una porción de funcionalidad de ese criterio de aceptación, nuevamente, escribe la prueba funcional más simple que podría fallar, ejecutarla, verla fallar y verificar que falla por la razón correcta. Luego, escribe una prueba unitaria fallida, la prueba unitaria más simple que posiblemente podría fallar, ejecútela, mírela fallar, verifique que falle por la razón correcta.
Ahora , escribe el código de producción más simple que posiblemente podría cambiar el mensaje de error. Ejecute la prueba nuevamente, verifique que el mensaje de error haya cambiado, que haya cambiado en la dirección correcta y que el código haya cambiado el mensaje por la razón correcta. (Idealmente, el mensaje de error ya debería haber desaparecido, y la prueba debería pasar, pero la mayoría de las veces, es mejor dar pequeños pasos para cambiar el mensaje en lugar de tratar de pasar la prueba de una vez; esa es la razón ¡Por qué los desarrolladores de marcos de prueba gastan tanto esfuerzo en sus mensajes de error!)
Una vez que aprueba la prueba unitaria, refactoriza su código de producción bajo la protección de sus pruebas. (Tenga en cuenta que en este momento, la prueba de aceptación y la prueba funcional aún fallan, pero está bien, ya que solo está refactorizando unidades individuales que están cubiertas por pruebas unitarias).
Ahora crea la siguiente prueba unitaria y repite lo anterior, hasta que también pase la prueba funcional. Bajo la protección de la prueba funcional, ahora puede realizar refactorizaciones en varias unidades.
Este ciclo intermedio ahora se repite hasta que pase la prueba de aceptación, momento en el que ahora puede realizar refactorizaciones en todo el sistema.
Ahora, elige el siguiente criterio de aceptación y el ciclo externo comienza nuevamente.
Kent Beck, el "descubridor" de TDD (no le gusta el término "inventor", dice que la gente ha estado haciendo esto todo el tiempo, simplemente le dio un nombre y escribió un libro al respecto) utiliza una analogía de la fotografía y llama a esto "acercar y alejar".
Nota: no siempre necesita tres niveles de pruebas. Tal vez, a veces necesitas más. Más a menudo, necesitas menos. Si sus piezas de funcionalidad son pequeñas y sus pruebas funcionales son rápidas, puede sobrevivir sin ellas (o con menos pruebas unitarias). A menudo, solo necesita pruebas de aceptación y pruebas unitarias. O bien, sus criterios de aceptación son tan precisos que sus pruebas de aceptación son pruebas funcionales.
Kent Beck dice que si tiene una prueba funcional rápida, pequeña y enfocada, primero escribirá las pruebas unitarias, dejará que las pruebas unitarias conduzcan el código y luego elimine (algunas de) las pruebas unitarias nuevamente que cubran el código que también es cubierto por la prueba funcional rápida. Recuerde: el código de prueba también es un código que necesita ser mantenido y refactorizado, ¡cuanto menos haya, mejor!
Sin embargo, me pregunto si el enfoque basado en pruebas también se puede aplicar a otras formas de pruebas.
Realmente no aplicas TDD a las pruebas. Lo aplicas a todo tu proceso de desarrollo. Eso es lo que significa la parte "impulsada" de Test- Driven -Development: todo su desarrollo es impulsado por pruebas. Las pruebas no solo controlan el código que escribes, sino que también controlan qué código escribir y qué código escribir a continuación. Impulsan su diseño. Te dicen cuando hayas terminado. Te dicen en qué trabajar a continuación. Le informan sobre fallas de diseño en su código (cuando las pruebas son difíciles de escribir).
Keith Braithwaite ha creado un ejercicio que llama TDD como si lo quisieras decir . Consiste en un conjunto de reglas (basadas en las Tres Reglas de TDD del Tío Bob Martin , pero mucho más estrictas) que debe seguir estrictamente y que están diseñadas para guiarlo hacia la aplicación de TDD de manera más rigurosa. Funciona mejor con la programación de pares (para que tu pareja pueda asegurarse de que no estás rompiendo las reglas) y un instructor.
Las reglas son:
- Escriba exactamente una prueba nueva, la prueba más pequeña que pueda que parezca apuntar en la dirección de una solución
- Véalo fallar; las fallas de compilación cuentan como fallas
- Haga que la prueba de (1) pase escribiendo el menor código de implementación que pueda en el método de prueba .
- Refactorizar para eliminar la duplicación y, de lo contrario, según sea necesario para mejorar el diseño. Sea estricto sobre el uso de estos movimientos:
- desea un nuevo método: espere hasta el momento de refactorización, luego ... cree nuevos métodos (que no sean de prueba) haciendo uno de estos, y de ninguna otra manera:
- preferido: hacer Extraer método en el código de implementación creado según (3) para crear un nuevo método en la clase de prueba, o
- si debe: mover el código de implementación según (3) a un método de implementación existente
- desea una nueva clase: espere hasta el momento de refactorización, luego ... cree clases que no sean de prueba para proporcionar un destino para un Método Move y sin ninguna otra razón
- llenar clases de implementación con métodos haciendo Move Method, y de ninguna otra manera
Estas reglas están destinadas a ejercer TDD. No están destinados a hacer TDD en producción (aunque nada impide que lo pruebes). Pueden sentirse frustrantes porque a veces parecerá que das miles de pequeños pasos sin hacer ningún progreso real.
