¿Cómo obtener la API inicial correcta usando TDD?

Esta podría ser una pregunta bastante tonta ya que estoy en mis primeros intentos de TDD. Me encantó la sensación de confianza que brinda y, en general, una mejor estructura de mi código, pero cuando comencé a aplicarlo en algo más grande que los ejemplos de juguetes de una clase, me encontré con dificultades.

Supongamos que estás escribiendo una especie de biblioteca. Sabe lo que tiene que hacer, conoce una forma general de cómo se supone que debe implementarse (en cuanto a la arquitectura), pero sigue "descubriendo" que necesita realizar cambios en su API pública a medida que codifica. Quizás necesite transformar este método privado en un patrón de estrategia (y ahora debe aprobar una estrategia simulada en sus pruebas), quizás haya perdido una responsabilidad aquí y allá y dividir una clase existente.

Cuando está mejorando el código existente, TDD parece encajar muy bien, pero cuando escribe todo desde cero, la API para la que escribe las pruebas es un poco "borrosa" a menos que haga un gran diseño por adelantado. ¿Qué haces cuando ya tienes 30 pruebas en el método que cambió su firma (y para esa parte, el comportamiento)? Esas son muchas pruebas para cambiar una vez que se suman.

Lo que llama "gran diseño por adelantado", lo llamo "planificación sensata de la arquitectura de su clase".

No se puede desarrollar una arquitectura a partir de pruebas unitarias. Incluso el tío Bob dice eso.

Si no está pensando en la arquitectura, si lo que está haciendo es ignorar la arquitectura y lanzar pruebas juntas y hacer que pasen, está destruyendo lo que permitirá que el edificio permanezca en pie porque es la concentración en el estructura del sistema y decisiones de diseño sólidas que ayudaron al sistema a mantener su integridad estructural.

http://s3.amazonaws.com/hanselminutes/hanselminutes_0171.pdf , página 4

Creo que sería más sensato abordar TDD desde una perspectiva de validación de su diseño estructural. ¿Cómo sabes que el diseño es incorrecto si no lo pruebas? ¿Y cómo verifica que sus cambios sean correctos sin cambiar también las pruebas originales?

El software es "suave" precisamente porque está sujeto a cambios. Si no se siente cómodo con la cantidad de cambios, continúe adquiriendo experiencia en diseño arquitectónico, y la cantidad de cambios que necesitará hacer en las arquitecturas de sus aplicaciones disminuirá con el tiempo.

Si haces TDD. No puede cambiar la firma y el comportamiento sin haberlo conducido por pruebas. Entonces, las 30 pruebas que fallaron fueron eliminadas en el proceso o cambiadas / refactorizadas junto con el código. O ahora están obsoletos, es seguro eliminarlos.

¿No puede ignorar el rojo 30 veces en su ciclo rojo-verde-refactorizador?

Sus pruebas deben ser refactorizadas junto con su código de producción. Si puede permitirse, vuelva a ejecutar todas las pruebas después de cada cambio.

No tenga miedo de eliminar las pruebas TDD. Algunas pruebas terminan probando bloques de construcción para llegar al resultado deseado. El resultado deseado a nivel funcional es lo que cuenta. Las pruebas en torno a los pasos intermedios en el algoritmo que eligió / inventó pueden ser de gran valor o no cuando hay más de una forma de alcanzar el resultado o si inicialmente se encontró con un callejón sin salida.

A veces puede crear algunas pruebas de integración decentes, conservarlas y eliminar el resto. De alguna manera depende de si trabajas de adentro hacia afuera o de arriba hacia abajo y de cuán grandes pasos das.

Como acaba de decir Robert Harvey, probablemente esté intentando utilizar TDD para algo que debería ser manejado por una herramienta conceptual diferente (es decir, "diseño" o "modelado").

Intente diseñar (o "modelar") su sistema de una manera bastante abstracta ("general", "vaga"). Por ejemplo, si tiene que modelar un automóvil, solo tenga una clase de automóvil con algún método y campo vagos, como startEngine () y asientos int. Es decir: describa lo que quiere exponer al público , no cómo quiere implementarlo. Intente exponer solo las funcionalidades básicas (lectura, escritura, inicio, detención, etc.) y deje el código del cliente elaborado (prepareMyScene (), killTheEnemy (), etc.).

Escriba sus pruebas asumiendo esta sencilla interfaz pública.

Cambie el comportamiento interno de sus clases y métodos cuando lo necesite.

Si necesita cambiar su interfaz pública y su conjunto de pruebas, deténgase y piense. Lo más probable es que esto sea una señal de que hay algo mal en su API y en su diseño / modelado.

No es inusual cambiar una API. La mayoría de los sistemas en su versión 1.0 advierten explícitamente a los programadores / usuarios contra posibles cambios en su API. A pesar de esto, un flujo continuo e incontrolado de cambios en la API es una señal clara de un diseño incorrecto (o totalmente perdido).

Por cierto: por lo general, solo debe tener un puñado de pruebas por método. Un método, por definición, debe implementar una "acción" claramente definida en algún tipo de datos. En un mundo perfecto, esta debería ser una acción única que corresponde a una sola prueba. En el mundo real no es inusual (y no está mal) tener pocas "versiones" diferentes de la misma acción y pocas pruebas correspondientes diferentes. Por supuesto, debe evitar hacerse 30 pruebas con el mismo método. Esta es una señal clara de que el método intenta hacer demasiado (y su código interno se descontrola).

Lo miro desde la perspectiva del usuario. Por ejemplo, si sus API me permiten crear un objeto Person con nombre y edad, es mejor que haya un constructor Person (string string, int age) y métodos de acceso para name y age. Es simple crear casos de prueba para personas nuevas con y sin nombre y edad.

doug