TDD supone que las interfaces ya están definidas; ¿como hacer frente?

Question

Para escribir pruebas antes del código, debe tener una forma de interactuar con el código. Las pruebas tienden a definir las interfaces mucho antes de tiempo para que las pruebas puedan escribirse.

Pero a menudo desarrollar una buena implementación implica inventar un conjunto de buenas interfaces entre componentes, ajustar y rehacer estas interfaces muchas veces. Durante esto, puede continuar reescribiendo buenas partes del código de prueba o permitir que las pruebas se retrasen con respecto al código.

¿Existen mejores prácticas para aliviar esto?

Answer 1

Esto suena como todo el ciclo de refactor rojo-verde. Es decir, TDD es - más o menos - sobre esta reescritura de interfaces. Esto los mantiene magros y al grano. Una vez que te acostumbras a TDDing, y escribes tus pruebas orientadas a la interfaz y mantienes tus objetos pequeños, no deberías ver muchos cambios a menos que toques algo imprevisto y debes adaptarte, que es el punto de ser ágil (que es con suerte por qué está TDDing)

Parece que está definiendo interfaces completas de una sola vez. Lo cual estaría mal. Una prueba debe generar una función en la interfaz y su comportamiento esperado. Su interfaz crecerá con el conjunto de pruebas, lo que minimiza aún más el back-patching.

Answer 2

Acepto @Per Fagrell -s "La interfaz crecerá con el tiempo".

alternativa: si va a crear businessclasses con una amplia funcionalidad ¿qué hay de definir interfaces multible para diferentes aspectos o subfunciones

Answer 3

Del mismo modo que escribir pruebas como si el código que está probando ya fueron escritos, puede (y debería) escribirlos como si la interfaz ya estuviera escrita. Esa es la pieza Design - la parte más importante - de Test-Driven Design. Usted sabe qué funcionalidad está a punto de solicitar de su clase bajo prueba; escriba la prueba como si esa funcionalidad ya estuviera allí. Los nombres y parámetros que usa ahora, en su prueba; lo que ocurre naturalmente para usted, pensando como cliente del código y la interfaz que se está probando; estos elementos tienen un lugar destacado en el diseño de su clase y su interfaz.

Answer 4

La prueba de unidad defectuosa no es solo la falla de las comprobaciones. La compilación de prueba unitaria fallida también se puede considerar como una prueba fallida. Por lo tanto, escriba sus pruebas unitarias ya que las interfaces están ahí.

TDD - diseño impulsado por prueba: significa cambiar las interfaces.