El ciclo TDD es prueba, código, refactor, (repetir) y luego enviar. Como su nombre implica TDD, el proceso de desarrollo es impulsado mediante pruebas, específicamente que significa writing tests first antes de desarrollar o escribir código.
El primer párrafo es de carácter puramente definitorio ... desde cómo Kent Beck defines TDD ... o cómo Wikipedians generally understand TDD ... pensé que era necesario agotar el tema con esta definición, porque no estoy seguro de si todo el mundo está realmente discutir el mismo TDD o si otros realmente entienden las implicaciones de la [parte más importante o la] definición de TDD, las implicaciones de las pruebas de escritura primero. En otras palabras, creo que el enfoque de las respuestas a esta pregunta debería profundizar un poco más en TDD, en lugar de explicar un sesgo a favor/en contra de UML. La parte larga de mi respuesta se refiere a mi opinión sobre el uso de UML para admitir TDD ... UML es solo un lenguaje de modelado, ciertamente no requerido para hacer TDD; podría interferir si se aplica de forma inapropiada ... pero UML puede ayudar a comprender los requisitos para escribir pruebas, cómo el modelado puede ayudar a refactorizar si es necesario y cómo la recopilación de los artefactos del proceso acelera la documentación del código enviado. Me gustaría recibir cualquier comentario, crítica o sugerencia, pero no vote mi respuesta porque usted está de acuerdo o no con el primer párrafo ... el acrónimo de TDD es Desarrollo basado en pruebas, lo que significa desarrollo basado en pruebas. .
Escribiendo una prueba primero implica que el desarrollador entiende las especificaciones y requisitos PRIMERA ... obviamente, cualquier prueba que se escribe debe fallar hasta que el código se escribe, pero en TDD, la prueba de debe escribirse first - no puede hacer TDD sin estar enfocado en comprender una especificación de requisitos antes de escribir pruebas, antes de escribir el código. Hay situaciones donde los requisitos no existen en absoluto; la obtención de requisitos implica un poco de hackear una versión pre-pre-alfa para "tirar el barro a la pared para ver qué se pega" ... ese tipo de cosas no se deben confundir con el desarrollo, ciertamente no con el desarrollo basado en pruebas, básicamente es solo una forma de requisitos: la obtención de un dominio de aplicación poco conocido.
Los diagramas UML son una forma de requisitos de entrada para TDD. No es el único, pero probablemente sea mejor que las especificaciones escritas si hay personas con conocimiento en la creación de diagramas UML. A menudo es mejor trabajar con diagramas visuales para una mejor comunicación al explorar el dominio del problema [con usuarios/clientes/otros proveedores de sistemas] durante las sesiones de modelado de requisitos previos a la implementación ... donde simular el rendimiento es necesario para comprender realmente los requisitos (p. Ej.); a menudo es ideal si podemos trabajar con un lenguaje de especificación o herramienta CASE como Rhapsody o Simulink RT Workshop que puede ser ejecutable, modular y completo ... UML no es necesariamente parte de TDD, pero es parte de una síntesis de diseño de enfoque que implica gastar más esfuerzo entendiendo lo que se requiere primero antes de escribir cualquier código [y luego perder el tiempo intentando comercializar ese código a alguien que se preocupa]; en general, un mayor enfoque en la comprensión de los requisitos del sistema sienta las bases para unas iteraciones TDD ágiles, más eficientes y productivas.
La refabricación se trata de mejorar el diseño, limpiar el código de trabajo probado, para que sea más simple, más fácil de mantener. Desea ajustarlo tanto como sea posible para eliminar los enredos confusos en los que los errores podrían estar ocultos o podrían aparecer en versiones futuras; no se refactoriza porque un cliente lo necesita; Usted refactoriza porque es más barato enviar un código limpio en lugar de seguir pagando el costo de soportar/mantener el complejo desastre. Generalmente, la mayor parte de TDD está más enfocada en el código; pero, podrías emplear UML para mirar un alcance mayor o dar un paso atrás para ver el problema, p. creando un diagrama de Clase para ayudar a identificar pruebas [faltantes] o posibles refactorizaciones. Esto no es algo que tendría que ordenar o querer hacer de forma general, pero cuando sea apropiado.
El último paso, 'enviar' es un paso serio ... 'barco' no es una abreviatura para "tirarlo por la pared y olvidarlo, porque un buen código no necesita ayuda" o "abandonar y esperar que no hay más iteraciones ". Desde una perspectiva financiera o comercial, el envío es el paso más importante de TDD, porque es donde le pagan. El envío implica un "cambio de marchas" porque incluye integración de sistemas, preparación para soporte y mantenimiento, preparación para la próxima ronda de desarrollo, etc. El uso principal de los diagramas UML será comunicar [en términos abstractos] cómo funciona el código lo que hace ... UML es útil porque, con suerte, los diagramas son un artefacto de los requisitos y procesos de desarrollo; no es necesario comenzar desde cero cuando el código se envía ... como herramienta de comunicación, UML sería apropiado para reducir los errores de integración sistemas de múltiples módulos, proyectos más grandes que podrían involucrar módulos escritos en diferentes idiomas, redes de sistemas integrados donde diferentes compañías debe colaborar en sistemas críticos para la seguridad, pero necesita que la abstracción sea tacaña o protectora de su "conocimiento propietario".
Igual que debe evitar el uso de un martillo grande en situaciones en las que un destornillador pequeño es apropiado O no va a llegar a ninguna parte pidiendo a todos los desarrolladores que estandaricen el uso de Emacs como editor. A veces la vista no vale la pena ascender: no querrás siempre arrastrar la pancarta de UML o ser conocido como el tipo que siempre estaba presionando a UML ... particularmente no en situaciones donde no hay sustituto para escribir pruebas o leer código. Si se atiene a las situaciones apropiadas, no debe temer utilizar UML como lenguaje de comunicación en todas las situaciones en las que el idioma lo ayude.
@Downvoter: no importa a menos que diga _por qué_ votó negativamente. –
Las pruebas unitarias primero requieren que el desarrollador sepa qué necesita hacer la unidad. Parece útil entonces tal vez solidificar lo que piensas que debería ser el código para que al menos tengas una idea de cuáles podrían ser las responsabilidades de cada clase. Si terminan siendo algo completamente diferente al final, eso también está bien. Mientras no se piense que es inamovible, UML parece una buena manera de poner en marcha la pelota si no puede encontrar un lugar para comenzar. –