El problema clave con el código heredado es que no tiene pruebas. Por lo tanto, debe agregar algunos (y luego más ...).
Esto en sí mismo requeriría mucho trabajo, como señaló @mattnz. Pero el problema especial del código heredado es que nunca fue diseñado para ser comprobable . Por lo tanto, generalmente es un gran lío enrevesado de código de espagueti, donde es muy difícil o francamente imposible aislar piezas pequeñas para realizar pruebas unitarias. Entonces, antes de las pruebas unitarias, debe refactorizar el código para que sea más comprobable.
Sin embargo, para refactorizar de manera segura, debe realizar pruebas unitarias para verificar que no haya roto nada con sus cambios ... Esta es la trampa 22 del código heredado.
El libro le enseña cómo salir de esta trampa haciendo los cambios mínimos y más seguros al código solo para habilitar las primeras pruebas unitarias. No se pretende que el diseño sea más agradable, solo para permitir pruebas unitarias. De hecho, a veces hacen que el diseño sea más feo o más complejo. Sin embargo, le permiten escribir pruebas, y una vez que tenga las pruebas unitarias en su lugar, tiene la libertad de mejorar el diseño.
Hay muchos trucos para hacer que el código sea comprobable: algunos son obvios, otros no. Hay métodos que nunca hubiera pensado en mí, sin leer el libro. Pero lo que es aún más importante es que Feathers explica lo que precisamente hace que una unidad de código sea comprobable. Necesita cortar dependencias e introducir barreras en su código, pero por dos razones distintas:
- detección : para verificar y verificar los efectos de ejecutar un fragmento de código, y
- separación : en primer lugar, para obtener el fragmento de código específico en un arnés de prueba.
Cortar dependencias de forma segura puede ser complicado. Introducir interfaces, simulacros e Inyección de dependencias es un objetivo limpio y agradable, pero no es necesariamente seguro hacerlo en este momento. Entonces, a veces tenemos que recurrir a la subclase de la clase bajo prueba para anular algún método que normalmente, por ejemplo, iniciar una solicitud directa a un DB. Otras veces, incluso podríamos necesitar reemplazar una clase / jar de dependencia con una falsa en el entorno de prueba ...
Para mí, el concepto más importante introducido por Feathers son las costuras . Una costura es un lugar en el código donde puede cambiar el comportamiento de su programa sin modificar el código en sí . La construcción de costuras en su código permite separar el fragmento de código que se está probando, pero también le permite detectar el comportamiento del código que se está probando incluso cuando es difícil o imposible hacerlo directamente (por ejemplo, porque la llamada realiza cambios en otro objeto o subsistema , cuyo estado no es posible consultar directamente desde el método de prueba).
Este conocimiento le permite notar las semillas de la capacidad de prueba en el montón de código más desagradable, y encontrar los cambios mínimos, menos disruptivos y más seguros para llegar allí. En otras palabras, para evitar hacer refactorizaciones "obvias" que tienen un riesgo de romper el código sin que lo notes - ya que ni aún tiene las pruebas de unidad para detectar eso.