Respuesta.

La automatización de las pruebas del código heredado es uno de los mayores problemas clásicos en el ámbito de TI.

Historia de la cuestión: Muchas empresas se enfrentan a la necesidad de probar sistemas que se escribieron sin tener en cuenta la automatización futura. A menudo, estos proyectos tienen una documentación deficiente, una alta deuda técnica y la falta de componentes aislados.

Problema: Las principales dificultades surgen debido a

la falta de ganchos de prueba y puntos de integración
la imposibilidad de aislar datos para la prueba
la fuerte interdependencia de los módulos
el gran número de anomalías y cambios no reflejados en el código

Solución: Por lo general, el proceso avanza paso a paso:

Análisis del sistema: es necesario identificar los procesos comerciales críticos y acordar el alcance de la cobertura de las pruebas automáticas.
Implementación de puntos de prueba: en la medida de lo posible, parte del código se envuelve en proxies, se adapta para duplícates de prueba o se utiliza el patrón de inyección de dependencias.
Cobertura de pruebas automáticas paso a paso: se escriben primero pruebas para el código "más simple" y menos relacionado.
Soporte continuo y refactorización: después de agregar pruebas, se utilizan como red de seguridad para mejoras.

Características clave:

Las pruebas a menudo no se empiezan desde cero, sino desde "envolturas" sobre funciones existentes.
Es necesario agregar la capacidad de prueba en la arquitectura por etapas.
El negocio debe estar lo más involucrado posible en la regulación de los escenarios críticos.

Preguntas capciosas.

¿Se pueden empezar a escribir pruebas automáticas antes de realizar una refactorización completa del código heredado?

Sí, a menudo las pruebas automáticas son necesarias precisamente para asegurar la refactorización. No se debe esperar una "perfección" total; por el contrario, las pruebas ayudan a hacer cambios con confianza.

¿Se debe intentar de inmediato cubrir todo el código heredado con pruebas automáticas?

No. Se debe enfocarse en los escenarios más riesgosos y utilizados con frecuencia. Cubrir "todo de una vez" perjudica la velocidad y no tiene sentido.

¿Es obligatorio implementar patrones modernos como DI para probar el código heredado?

No, pero se recomienda su uso si los recursos lo permiten. El primer paso es al menos un aislamiento parcial, mocks y puntos de prueba especiales en el código.

Errores comunes y antipatrón

Migrar todo el código a la vez a las pruebas automáticas — los proyectos se detienen y pierden sentido comercial.
Cobertura "paranoica" de funciones insignificantes.
Falta de comunicación entre desarrollo, pruebas y negocio.

Ejemplo de la vida real

Caso negativo

El equipo intentó implementar pruebas automáticas reescribiendo toda la antigua aplicación según los patrones SOLID y cubriendo el 100% del código con pruebas.

Pros:

Mejora básica de la arquitectura.
A largo plazo, las pruebas pueden ser beneficiosas.

Contras:

Un simple desarrollo que duró varios meses.
Errores constantes y desincronización con los requisitos del negocio.
Pérdida de relevancia del código para cuando se escribieron las pruebas.

Caso positivo

Implementaron pruebas automáticas solo para los puntos críticos de cálculo a la par de implementar stubs especiales, modificando mínimamente el código general.