Por qué Test-Driven Development

Test Driven Development (TDD) es una técnica usada por ingenieros de software experimentados para asegurar el estado de una aplicación tal como se pretende. En aplicaciones más tradicionales y dentro del recorrido de la ingeniería de software en general, el testing ha sido reconocido y consolidado como parte de cada sistema de software exitoso y elaborado profesionalmente. Hoy en día, sigue habiendo toneladas de empresas que tienen la impresión de que escribir tests ralentiza el desarrollo, aumenta costes y en general es una pérdida de tiempo. Que este artículo arroje luz sobre por qué esa afirmación en particular no podría estar más equivocada.

¿Qué impide que el software funcione?

No existe el software escrito perfectamente. (Probablemente) nunca lo habrá. El término bug se acuñó por primera vez en Harvard en 1946. En ese momento, Grace Hopper había popularizado una historia sobre una polilla que causó problemas en un computador electromecánico temprano. Hopper estaba trabajando en los sistemas de computación Mark II/III en Harvard donde identificó que una polilla estaba atrapada en un relé causando problemas.

Una vez que se removió la polilla Hopper acuñó la frase en sus notas: "First actual case of bug being found". El término "bug" fue creado y usado desde entonces para indicar comportamiento inesperado en un sistema computacional. ¿Cuál es la probabilidad de que cierto sistema tenga bugs? 100 de 100 proyectos. ¿Cuál es la probabilidad de tener bugs dentro de cierto sistema, si contrato a los mejores ingenieros del planeta? 100 de 100 proyectos. Por lo tanto, contratar mejores ingenieros no resuelve el problema. Definitivamente disminuirá la cantidad de bugs, pero no su presencia general. Es por eso que se escriben tests, ya que no hay software libre de errores.

El bug de Grace Hopper (1946)

TDD: Recortando Costes, Mejorando Calidad

En Test-Driven Development (TDD), los ingenieros escriben los tests antes de implementar la lógica. Sin entrar en detalles técnicos, esto lleva a lo siguiente: Asegura, si se hace adecuadamente, que ningún código sin tests se pushea al repositorio ya que has escrito un test dedicado por adelantado. ¿Resuelve esto el problema de bugs que hemos discutido arriba? Desafortunadamente, no lo hace. Pero es una de las mejores técnicas que tenemos para asegurar la creación de software resistente y probado en batalla.

"Valida suposiciones temprano para minimizar errores costosos después"

¿Cuál es la diferencia con web3 ahora? La seguridad es una prioridad principal en el desarrollo Web3. Los smart contracts a menudo manejan cantidades significativas de criptomoneda y otros activos digitales valiosos. Cualquier vulnerabilidad en estos contratos puede llevar a pérdidas financieras sustanciales. TDD juega un papel crucial al mejorar la seguridad promoviendo testing continuo e identificación temprana de problemas potenciales.

Al atrapar fallos de seguridad temprano en el ciclo de desarrollo, TDD ayuda a proteger contra exploits y ataques que podrían comprometer la integridad de una aplicación descentralizada. El testing permite a los ingenieros ajustar el codebase y recibir feedback inmediato. Si los tests están escritos adecuadamente, cualquier cambio al codebase que pudiera llevar a un bug será atrapado por un test y reportado.

Es importante decir que todo lo mencionado arriba se puede hacer con testing simple también. Testing simple en el sentido de escribir un test cuando creemos que "ahora" es un buen momento. Muchos ingenieros siguen el camino: "Escribo el código ahora y una vez que tenga tiempo, escribiré el test". Lo cual está, hasta cierto grado, OK. ¡Mejor que no escribir tests en absoluto! Aun así nunca alcanzará los niveles de resiliencia de TDD, porque pierde por completo el punto. Felizmente me repito aquí: "Ningún código sin tests llegará a producción". Esto es lo que el TDD puro asegura.

No tener tests en absoluto eventualmente saldrá mal

El Asesino Silencioso: Deuda Técnica

Ahora todavía te debo una explicación de por qué omitir escribir tests disparará los costes de ingeniería y mantenimiento. La palabra clave es deuda técnica. El software siempre contendrá bugs. Cuanto más exista y más grande se vuelva, más bugs producirá. Esto no es algo que me inventé para subrayar esta sección, es un hecho conocido. En consecuencia, si no hay contramedida para encontrar y eliminar estos bugs, vivirán e influenciarán el código que se añada al codebase. Regularmente. Cuantos más features añadamos a ese software, más grande se vuelve el problema. Y entonces un día, la torre colapsa y estás de pie frente a una base de código que ya no es controlable.

Llevando a una reconstrucción total o parcial de tu proyecto.

Imagina un pueblo pequeño que decide construir un puente rápidamente para conectar dos lados de un río. Los ingenieros, en su prisa, se saltan algunas comprobaciones de seguridad y usan materiales de menor calidad. Inicialmente, el puente funciona bien, y todos están contentos con la finalización rápida. A medida que pasa el tiempo, más y más coches empiezan a usar el puente. Aparecen pequeñas grietas, pero se ignoran porque el puente todavía está en pie. Cada vehículo nuevo añade estrés, haciendo esas grietas más grandes. Un día, un camión muy cargado conduce por el puente, y colapsa, causando una disrupción masiva.

Esto es lo que pasa con la deuda técnica en software. Los atajos tempranos y el código sin tests crean problemas ocultos. A medida que se añaden nuevos features, estos problemas crecen hasta que el sistema se vuelve frágil. Eventualmente, un cambio aparentemente menor puede causar un fallo catastrófico, al igual que el camión sobrecargado le hizo al puente. Sin tests para atrapar y arreglar issues temprano, el software se vuelve insostenible, llevando a costes disparados y, finalmente, colapso.

Consejo #1: Cuando contrates desarrolladores, testea su competencia en testing haciendo preguntas simples:

→ ¿Cuál es tu experiencia escribiendo tests?
→ ¿Qué tipo de tests prefieres para este proyecto, y por qué?
→ ¿Realmente necesitamos escribir tests?

Consejo #2: Si les importa una M* el testing, les importa una M* tu producto.

Suena duro, pero es la verdad.

Tu proyecto eventualmente morirá sin testing, eso es seguro.