Vamos a repasar de nuevo esas cuatro reglas del código sostenible profundizando un poquito más en cada una de ellas.

1. El código está bien cubierto por test automáticos:

• 
  
  • Es absolutamente imprescindible saber escribir buenos test y proveer de la cobertura adecuada.
  • Los test nos permiten introducir cambios sin romper funcionalidades.
  • Los test son nuestra red de seguridad a la hora de hacer refactoring.

La primera habla de la cobertura de test, de que un proyecto debe tener una buena cobertura de test de diverso tipo (de integración, unitarios, ...) en la proporción adecuada para que podamos introducir cambios y si algo se ha roto nos avisen. Al final, es imposible que podamos escribir código perfecto por más que sepamos del dominio o por más que parezca que todo está claro. La única manera de sostenernos en el tiempo es mediante refactorización permanente, y la única manera de hacer refactorización segura es teniendo esa cobertura de test que nos respalde. Por eso, cuando hay equipos que quieren cuidar la calidad de su software, de su código base, pero no hacen test, por más que añadan una arquitectura hexagonal, implementen patrones de diseño, intenten aplicar Domain Driven Design, etc., a pesar de todo eso, si se olvidan de los test unitarios, los de integración, etc., no van a poder mantener calidad a lo largo del tiempo porque van a tener siempre miedo y van a romper funcionalidades.

2. Los test son sostenibles:

• 
  
  • Escribir test no es suficiente, es fundamental que sean de calidad.
  • Evitar escribir test frágiles que se rompen cuando los requisitos no cambian.
  • Los test deben estar desacoplados de la implementación.

La segunda regla dice que los test tienen que ser sostenibles, y es que cuando no tienes experiencia desarrollando con test, rápidamente, en tu primer proyecto, vas a acabar con cientos o miles de test, lo cual es normal, pero en ocasiones esos test te van a impedir que puedas hacer cambios en el código porque se van a romper demasiados test cuando cambias cosas que, en teoría, no deberían romperse porque no han cambiado los requisitos del negocio y esto pasa porque los test están demasiado acoplados a la implementación, quizá se abusa de los mocks, quizá su scope o ámbito es demasiado grande, puede que el nombre de los test no sea adecuado, etc.. Hay un sinfín de motivos por el que esos test se pueden volver en contra y ralentizar el desarrollo, de ahí la importancia de saber escribir buenos test de manera sostenible.