Test driven development

Test driven development… o desarrollo dirigido por pruebas… deberías aprenderlo? es tan difícil como dicen?

Si!, deberías, pero de la forma correcta y fácil, no complicándolo más de lo que es!

Velocidad de desarrollo

Quizás esta es la principal razón por la que muchos nos negamos (yo al comienzo lo encontraba una pérdida de tiempo) a aprender testing. Y las razones no son para extrañarse… escribes código, funciona y además debes escribir los tests. ¡Eso ya suena al doble de trabajo!, y la verdad es que lo es, siempre y cuando tu base de código sea pequeña. ¿Qué tan pequeña? Tal vez unas cuantas semanas o meses de un desarrollador. Y la verdad es dura, es mucho más rápido que nosotros hagamos click o pinchemos en nuestra aplicación y veamos si el resultado es el correcto, sobre todo si aún no te has sumergido en el mundo de las pruebas automáticas. Pero luego de un tiempo comenzarás a ver la frustración.

Tu proyecto ya creció, ya tiene más de varios meses de desarrollo, se te olvidó como implementaste esa funcionalidad hace tiempo, pero sigues lanzando nuevas funcionalidades y, de pronto, empiezan a llegar los reportes de errores. El usuario A no puede ingresar a la funcionalidad B, lo corriges y BOOM! otro reporte de error, rompiste otra funcionalidad, tu estrés se empieza a acumular, los usuarios empiezan a quejarse, la gente te empieza a mirar mal y empiezan a dudar de la calidad de tu trabajo… esto es algo NORMAL!, todos pasamos por eso alguna vez, y la verdad es que las personas saben que existen errores en el desarrollo de software, pero también saben que necesitan un producto funcionando y que opere en el largo plazo. Esto ya es una necesidad, por así decirlo como la ley del software, si no funciona no sirve. ¡Y todos quieren sacar software rápido!

En el largo plazo el testing automático logrará que reduzcas los tiempos de pruebas y también te ayudará a transparentar si cometiste un error y rompiste otra funcionalidad. Es muy importante que tomes en cuenta de que, si es un proyecto pequeño (just4fun) no es tan necesario, pero si este proyecto cumple con que será un proyecto a largo plazo, en ese caso el testing será algo primordial.

Las empresas hoy en día buscan personas que sean capaces de testear su propio código y, como bonus, que puedan escribir tests para el código de otros, ¡no te imaginas los dolores de cabeza que les ahorrarás! y dólares también les ahorrarás.

Calidad del código

Escribir tests no es fácil, sobre todo si el código escrito parece un tallarín, pirámide de la muerte o patrón MVC (acá nos gusta la programación funcional orientada a eventos :D). Esto te va a forzar a escribir el código de otra forma y te hará amar patrones que, si bien existen hace muchos años, ¡hacen que todo sea mucho más sencillo!

• Inyección de dependencias
• Publish/subscribe

Estos permiten desacoplar el código, ¡lo que hace que escribir tests a tus funciones sea mucho más sencillo!

Documentación

Los tests además te permiten generar documentación, como utilizar la API de una librería a módulo que escribiste, también le dice a otros desarrolladores que esperarse de tu código!

Despliegue con confianza!

¡No hay nada más tranquilizador que saber que tu código no ha roto nada, que todo funciona y que puedes realizar el paso a producción con confianza!

Spoiler!

Los tests prueban lo que tú quieres probar, es buena práctica siempre redactar a lo menos la descripción de lo que quieres probar antes de comenzar con la implementación, y siempre comenzar manejando el error, ¡porque tendrás errores! Esto quiere decir que de todas maneras en tu código habrá errores que no estas capturando y que nadie detectó a tiempo, pero te aseguro que ¡van a ser mucho menos errores que los que tenías antes!