El código limpio que nadie puede verificar es solo código que todavía no ha roto nada.
El buen código no es opcional. Eso ya lo sabes. Pero hay algo que mucha gente se deja en el camino.
¿Cómo sabes que tu código "limpio" sigue funcionando después de refactorizarlo?
Imagina esto: es un viernes por la tarde. Te sientas a refactorizar un servicio que lleva meses pidiendo a gritos una limpieza. Renombras métodos, los extraes a un nuevo módulo, introduces abstracciones que antes no existían. Cuando terminas, el código brilla. Es una obra de arte.
Y entonces viene la pregunta incómoda.
¿Cómo sabes que no has roto nada? ¿Que el flujo de pedidos sigue funcionando de extremo a extremo? ¿Que la integración de pagos no se ha roto silenciosamente? ¿Que un cliente todavía puede completar una compra?
No lo sabes. No puedes saberlo, a menos que tengas tests que verifiquen el comportamiento del sistema, no la implementación.
El código sostenible necesita una red de seguridad
Los tests unitarios son rápidos. Te dan feedback inmediato y hacen que refactorizar se sienta seguro. Son el pan de cada día de cualquier desarrollador disciplinado.
Pero incluso los mejores tests unitarios tienen un punto ciego enorme.
Verifican piezas en aislamiento. Mockean la base de datos. Stubean la API externa. Se saltan la serialización. Cuando todos los tests pasan, sabes que la lógica de tu unidad funciona correctamente. Pero no sabes si la lógica del sistema funciona.
Los problemas aparecen en los límites. La consulta que devuelve datos con una forma diferente a la que asumías. La capa HTTP que silenciosamente se come un campo. La integración que funcionaba aislada pero se rompe cuando se encuentra con la realidad.
Los tests unitarios no pueden detectar estos problemas, no porque estén mal escritos, sino porque no están diseñados para eso. Nadie les pidió que lo hicieran.
Los tests de aceptación llenan ese hueco
Los tests de aceptación ejercitan el sistema de extremo a extremo, a través de los mismos límites que tocan tus usuarios reales.
La diferencia con los unitarios no es solo técnica, es conceptual:
- Un test unitario dice: "Esta función calcula el descuento correctamente."
- Un test de aceptación dice: "Cuando un cliente aplica un cupón en el checkout, el precio total se reduce y el pedido se completa."
Uno verifica una pieza. El otro verifica una historia. Uno te dice que la función hace lo que se supone. El otro te dice que el usuario puede hacer lo que necesita.
Ambos son necesarios. Son complementarios, no competidores. Pero el segundo es el que te deja dormir tranquilo después de un viernes de refactoring.
¿Y si tienes un proyecto legacy sin un solo test?
Esta es la pregunta real. La que tienen la mayoría de desarrolladores .NET que trabajan en proyectos con años de historia encima.
Aquí está la trampa en la que caen muchos: intentan escribir tests unitarios primero en código legacy. Es una batalla perdida. El código legacy no fue diseñado para ser testeado en aislamiento. Tiene dependencias estáticas, clases enormes, métodos que hacen diez cosas a la vez.
La estrategia más efectiva es la contraria: empieza por los tests de aceptación.
1. Escribe un test de aceptación que describa un flujo crítico.
2. Hazlo pasar tal cual está el código (sin tocar nada).
3. Ahora tienes una red de seguridad.
4. Refactoriza con confianza.
5. Añade tests unitarios a medida que extraes lógica.Los tests de aceptación sobre código legacy son feos, lentos, a veces frágiles. No importa. Su trabajo no es ser elegantes. Su trabajo es atrapar regresiones mientras tú limpias el desastre heredado.
Primero pon la red. Luego haz el salto.
La conclusión que no te puedes saltar
Refactorizar código sin cobertura de tests de comportamiento no es "limpiar". Es reorganizar la deuda técnica sin garantías. Puede quedar bonito en el repositorio y estar completamente roto en producción.
El código limpio sin tests es código que todavía no ha fallado en el peor momento. El código con una buena cobertura de aceptación es código que puedes cambiar sin miedo.
Y en este trabajo, cambiar código sin miedo no es un lujo. Es la habilidad que te hace relevante.
No comments:
Post a Comment