¿Por qué hacemos tests?
Imagínate entrando al sitio web de tu banco a chequear cuánto dinero te queda en la cuenta. Tienes 1000 dólares. El banco decide hacer una actualización al sitio web durante la noche, y decides comprobar nuevamente tu saldo por la mañana. Ahora tienes 257,43 dólares. Te preguntas, ¿a dónde fue tu dinero? ¿Es ese realmente su saldo?
Reportas este inconveniente al servicio de atención al cliente. Miles de otros usuarios reportan problemas similares. Lo que lleva a que los clientes cierren sus cuentas.
En el banco descubren que la causa es un error de software, ya que los desarrolladores del banco no realizaron pruebas antes de implementar la actualización del sitio web. El dinero no desapareció pero sus cantidades fueron impresas incorrectamente a los usuarios.
¿Qué nos enseña esto?
Errar es de humanos, y siendo el desarrollo de software una actividad principalmente humana, no está exento de ello. De hecho, es inevitable que tu código tenga errores. Y si estos no se arreglan antes de llegar a producción, pueden tener un impacto doloroso y costoso en los usuarios y desarrolladores.
Por ejemplo, en 2002, un estudio comisionado por el Instituto Nacional de Estándares y Tecnología del Departamento de Comercio de los Estados Unidos concluyó que los errores de software le cuestan a la economía de los Estados Unidos alrededor de 59 mil millones de dólares anuales.
Para evitar esos costos, los desarrolladores creamos pruebas o tests, que se ejecutan antes, durante y después del despliegue a producción. Solemos utilizar las denominadas suites de test (nosotros usamos Cypress para nuestros tests de integración y Rspec para tests unitarios del backend) para ejecutar un conjunto de pruebas de forma automatizada, y así tener la confianza de que lo que estamos desarrollando está libre de errores y funciona como se espera.
Y si el ahorro que supone hacer pruebas no te ha convencido aún de su importancia, te daré otros dos grandes motivos:
1. La ley de Murphy
Para mí, crear tests significa aceptar definitivamente que no somos perfectos, que eventualmente las cosas podrían salir mal. Y que eso está bien, sólo hay que prepararse para ello. Todos cometemos errores. Y un día nos podemos olvidar de devolver los valores de nuestras funciones, de ejecutar los pasos en el orden correcto, de poner un paréntesis o simplemente la indentación. Finalmente, el propósito de las pruebas no es sólo mostrarnos cuándo tenemos errores, sino también señalar las cosas que podemos mejorar en nuestro proceso de desarrollo.
Al aceptarlo, pedir ayuda se vuelve mucho más sencillo, porque es más fácil aceptar que te equivocas cuando sabes que esto no tiene consecuencias desastrosas, que tienes un equipo que te respalda y está ahí para ayudarte a diagnosticar y arreglar el problema.
2. El equipo está primero
Por lo mismo, escribir pruebas me ayuda a demostrarle a mi equipo y a mi yo del futuro que me preocupo por ellos y por la calidad de lo que hacemos.
Antes de implementar un nuevo feature, suelo consultar el diseño, los casos de borde y el flujo ideal con el UX y Product Owner, haciendo mi tarea para reunir el contexto sobre cómo deberá comportarse la nueva característica que voy a desarrollar. Y en teoría, puedo usar este contexto para probarla manualmente, y todos podríamos confiar en que funciona.
¿Pero qué pasa con la siguiente persona que toque este código? Incluso si también hiciera su tarea, no hay garantía de que obtenga toda la misma información que recibí yo cuando lo escribí. Después de todo, esto podría pasar dentro de un período de un mes, un año o dos años más adelante. Entonces, ¿cómo sabe la siguiente persona que no está rompiendo algo?
Y creo que un gran temor con el que muchos se podrán identificar es a romper algo que no conoces. Y es por eso que cuando escribo test, no sólo me estoy ayudando a mí misma documentando las maneras en la que mi feature podría fallar, sino que también ayudo a la siguiente persona que quiera mejorarla.
A nadie le gusta estar en una situación en la que algo está mal y no lo sabe. Y todos esperamos contar con la confianza de saber que si rompemos algo, los tests nos lo van a informar. De esta manera evitamos cualquier tensión y la tratamos antes que sea demasiado tarde, que se incumpla un plazo o alguien se vea perjudicado. Porque al final, el desarrollar, y en especial, desarrollar las pruebas, es más que simple código.
No puedo arreglar todos los problemas que nuestro código tiene hoy, pero el pasar unos minutos cada día alineándonos con nuestros objetivos, sumado a la tarea de admitir errores, cuidar de los demás, y ser honestos con el lugar donde estamos, puede ayudar a empujarnos en la dirección correcta.
Con esto espero que hayas descubierto las virtudes de empezar a testear el código que realizas y le des más tiempo a escribir test, para así evitar escribir código que no hayas probado.
Así que ánimo que con mucha práctica y paciencia este camino se irá volviendo más fácil y si no sabes por donde empezar, puedes leer Test Driven Development: By Example por Kent Beck, donde explica como el TDD es una herramienta realmente poderosa al momento de crear software, que permite a un equipo desarrollar código mantenible y de alta calidad.
