Escritura de pruebas para el código cuyo propósito no entiendo

¡Lo estás haciendo bien!

Crear pruebas de regresión automatizadas es a menudo lo mejor que puede hacer para hacer que un componente sea refactorable. Puede ser sorprendente, pero estas pruebas a menudo se pueden escribir sin la comprensión completa de lo que hace el componente internamente, siempre y cuando se entiendan las "interfaces" de entrada y salida (en el significado general de esa palabra). Hicimos esto varias veces en el pasado para aplicaciones heredadas en toda regla, no solo para clases, y con frecuencia nos ayudó a evitar romper cosas que no entendíamos completamente.

Sin embargo, debe tener suficientes datos de prueba y asegurarse de tener una comprensión firme de lo que hace el software desde el punto de vista de un usuario de ese componente, de lo contrario, corre el riesgo de omitir casos de prueba importantes.

En mi humilde opinión es una buena idea implementar sus pruebas automatizadas antes , comience a refactorizar, no después, para que pueda realizar la refactorización en pequeños pasos y verificar cada paso. La refactorización en sí debería hacer que el código sea más legible, por lo que le ayuda a aumentar su comprensión de los elementos internos poco a poco. Así que los pasos del pedido en este proceso son

1. entienda el código "desde afuera",
2. escribir pruebas de regresión,
3. refactor, lo que lleva a una mejor comprensión de los aspectos internos del código

Una razón importante para escribir pruebas unitarias es que documentan el componente API de alguna manera. No entender el propósito del código bajo prueba es realmente un problema aquí. La cobertura del código es otro objetivo importante, difícil de lograr sin saber qué ramas de ejecución existen y cómo se activan.

Sin embargo, si es posible restablecer el estado limpiamente (o construir el nuevo objeto de prueba cada vez), se pueden escribir pruebas tipo "trash in-trash out" que solo alimentan una entrada mayormente aleatoria al sistema y observan la salida. .

Tales pruebas son difíciles de mantener, ya que cuando fallan, puede ser complejo decir por qué y cuán grave es. La cobertura puede ser cuestionable. Sin embargo todavía son mucho mejores que nada. Cuando dicha prueba falla, el desarrollador puede revisar los últimos cambios con más atención y, con suerte, detectar el error allí.