¿Lo estoy haciendo bien? Si no es exactamente lo que tengo que cambiar
Es difícil decir a partir de ese breve descripción, pero sospecho que no, usted está no haciendo bien. Nota: No estoy diciendo que lo que está haciendo no funciona o de alguna manera es malo, pero no está haciendo TDD. La "D" central significa "Impulsado", las pruebas conducen todo, el proceso de desarrollo, el código, el diseño, la arquitectura, todo .
Las pruebas le dicen qué escribir, cuándo escribirlo, qué escribir a continuación, cuándo dejar de escribir. Te cuentan el diseño y la arquitectura. (El diseño y la arquitectura emergen del código a través de la refactorización). TDD no se trata de pruebas. Ni siquiera se trata de escribir pruebas primero: TDD se trata de dejar que las pruebas lo conduzcan, escribirlas primero es solo un requisito previo necesario para eso.
No importa si realmente escribe el código o si está completamente desarrollado: está escribiendo (esqueletos de) código en su cabeza, luego escribe pruebas para ese código. Eso no es TDD.
Dejar ese hábito es difícil . Muy, muy duro. Parece ser especialmente difícil para programadores experimentados.
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 nueva prueba, 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 pasar la prueba desde (1) escribiendo el código de implementación mínimo 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 tiempo 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 la refactorización, luego ... cree clases que no sean de prueba para proporcionar un destino para un Método Move y sin ningún otro motivo
- llenar clases de implementación con métodos haciendo Move Method, y de ninguna otra manera
Por lo general, esto conducirá a diseños muy diferentes que el "método pseudo-TDD" que se practica con frecuencia de "imaginar en su cabeza cuál debería ser el diseño, luego escribir pruebas para forzar ese diseño, implementar el diseño que ya había imaginado antes de escribir su pruebas ".
Cuando un grupo de personas implementa algo como un juego de tic tac toe usando pseudo-TDD, generalmente terminan con diseños muy similares que involucran algún tipo de Boardclase con una matriz de 3 × 3 de Integers. Y al menos una parte de los programadores habrá escrito esta clase sin pruebas porque "saben que la van a necesitar" o "necesitan algo contra lo que escribir sus pruebas". Sin embargo, cuando obligas a ese mismo grupo a aplicar TDD como si lo quisieras, a menudo terminarán con una amplia diversidad de diseños muy diferentes, a menudo sin emplear nada ni remotamente similar a a Board.
¿Hay alguna forma de identificar si la prueba que ha escrito es suficiente?
Cuando cubren todos los requisitos comerciales. Las pruebas son una codificación de los requisitos del sistema.
¿Es una buena práctica escribir una prueba para una funcionalidad muy simple que podría ser equivalente a 1 + 1 = 2 o es solo una exageración?
Una vez más, lo tienes al revés: no escribes pruebas de funcionalidad. Escribes funcionalidad para pruebas. Si la funcionalidad para aprobar la prueba resulta trivial, ¡genial! ¡Acaba de cumplir un requisito del sistema y ni siquiera tuvo que trabajar duro para cumplirlo!
¿Es bueno cambiar la funcionalidad y probar si los requisitos cambian?
No. Al revés. Si un requisito cambia, usted cambia la prueba que corresponde a ese requisito, observa cómo falla y luego cambia el código para que se apruebe. Las pruebas siempre son lo primero.
Es dificil hacer esto. Necesitas docenas, tal vez cientos de horas de práctica deliberada para construir algún tipo de "memoria muscular" para llegar a un punto, donde cuando se acerca la fecha límite y estás bajo presión, ni siquiera tienes que pensar en ello. , y hacerlo se convierte en la forma más rápida y natural de trabajar.