Heredas un servicio sin tests y necesitas cambiar su lógica central. ¿Cómo lo abordas?

Fija el comportamiento actual antes de cambiarlo. Escribe tests de caracterización en una frontera estable, metiendo entradas reales y afirmando lo que el código hace hoy, bugs incluidos, para tener una red que detecte cambios. Después refactoriza en pasos pequeños con esos tests en verde, extrayendo la lógica que necesitas tocar a algo comprobable. Solo cuando existe esa costura cambias el comportamiento, y cada cambio lleva su propio test.

No cambio lógica que no puedo verificar, así que el paso uno es una red. Escribo tests de caracterización en la frontera estable más alta, normalmente el handler HTTP o un punto de entrada del servicio, y afirmo lo que el código hace ahora mismo, incluidas cosas que sospecho que son bugs. El objetivo no es la corrección, es detectar el cambio. Si tengo acceso a producción capturo unos cientos de pares reales de petición y respuesta, porque las entradas hechas a mano se pierden las raras y las raras son las que rompen. Después refactorizo en pasos pequeños con los tests en verde todo el camino, sacando la lógica que de verdad necesito tocar a una función que puedo llamar directamente. Solo entonces cambio el comportamiento, y cada cambio viene con un test real más una decisión sobre si el comportamiento antiguo era intencionado. En un servicio de precios heredado hice exactamente esto y el tráfico capturado dejó al descubierto dos caminos de redondeo que no coincidían, algo que nadie sabía. Ese es el tipo de cosa que encuentras con una red y destrozas sin ella.