14.6.2 Complejidad de la prueba El objetivo es luchar por la simplicidad en todo lo que hace dentro de TDD. Por lo tanto, escribes un prueba que falla, luego haga lo suficiente para que la prueba pase (pero no más). Entonces tú refactorizar el código de implementación (es decir, cambiar las partes internas de la unidad bajo prueba) para mejorar la base de código. Continúe haciendo esto hasta que toda la funcionalidad para un unidad ha sido completada. En términos de cada prueba, debe esforzarse nuevamente por la simplicidad. con cada prueba solo probando una cosa con una sola afirmación por prueba (aunque este es el tema de mucho debate dentro del mundo TDD). 14.6.3 refactorización El énfasis en la refactorización dentro de TDD hace que sea más que solo probar o probar Primer Desarrollo. Este enfoque en la refactorización es realmente un enfoque en el (re)diseño y mejora incremental. Las pruebas proporcionan la especificación de lo que se necesita como así como la verificación de que se mantiene el comportamiento existente, pero la refactorización conduce a un mejor diseño de software. Por lo tanto, sin refactorizar, ¡TDD no es TDD! 14.7 Diseño para la capacidad de prueba La capacidad de prueba tiene varias facetas. • Configurabilidad. Configure el objeto bajo prueba a una configuración apropiada para la prueba • Controlabilidad. Controlar la entrada (y el estado interno) • Observabilidad. Observa su salida • Verificabilidad. Que podamos verificar esa salida de manera adecuada. 14.7.1 Reglas generales de comprobabilidad Si no puede probar el código, cámbielo para que pueda hacerlo. Si su código es difícil de validar, ¡cámbielo para que no lo sea! ¡Solo se debe probar una clase concreta por prueba de unidad y luego simular el resto! Si su código es difícil de reconfigurar para que funcione con Mocks, hágalo para que pueda codificar puede usar simulacros! ¡Diseñe su código para que sea comprobable! 14.6 Desarrollo basado en pruebas 173