TDD: Técnicas de programación que mejorarán tu eficiencia

Para todos aquellos que no han tenido una aproximación al mundo de la programación y la ingeniería de software, puede parecer que esta labor es bastante compleja por sus procedimientos abstractos. 

Y no es para menos, la programación en principio requiere de procedimientos tanto lógicos como conceptos abstractos para ideas soluciones que satisfagan necesidades. 

Para ello, se emplean algunas técnicas de programación que cumplen una función específica, y que simplifican la tarea de crear soluciones o bien, el proceso de desarrollo en sí. 

Y aquí es donde entra en juego la técnica del TDD, un práctica que busca minimizar errores y maximizar la eficiencia o calidad del producto. 

Si eres amante de la programación te interesa (y mucho) saber más sobre esta práctica y sus beneficios. ¡Te lo contamos!

¿Qué es TDD?

TDD, cuyas siglas hacen referencia a Test Driven Development o «Desarrollo Basado en Pruebas» es, como su propio nombre lo indica, las pruebas que se realizan previo a la escritura propia del código fuente de cualquier aplicación o desarrollo de software. 

Antes de la década de los 90s, la escritura o desarrollo de software se implementaba por un estándar universal en el que el desarrollo constaba de «primero escribe, luego prueba». 

Es decir, la escritura de código venía primero y posterior a ello, se realizan los tests o pruebas para verificar que el código funcionaba correctamente. 

Esto cambió de forma radical cuando el desarrollador de Estados Unidos, Kent Beck, implementó un nuevo enfoque de desarrollo en el que proponía testear primero, y luego escribir. 

¿Cuál es el propósito de esta práctica? Te estarás preguntando, y es bastante sencillo y a su vez, lógico. 

Plantear en primera instancia las situaciones a las que se enfrentará la aplicación o software a desarrollar, antes de su escritura propiamente, hará que la misma sea mucho más eficiente minimizando lo mejor posible los errores o bugs. 

Puede que para una persona que está comenzando en el mundo del desarrollo de software,  este modelo de creación pueda ser algo contraproducente porque exige una lógica pensada en solventar problemas y necesidades futuras. 

Pero a su vez, es más eficiente ya que se identifican los casos comunes de fallas y se desarrolla el código indicado para superar el test.

3 Objetivos claves del TDD 

Ahora que ya conoces el funcionamiento y concepto de esta técnica de desarrollo, es importante poder destacar de manera puntual, cuáles son sus propósitos en la programación. 

Esto te brindará de una perspectiva clara en el momento de querer desarrollar, ya que establece de manera clara y precisa cuál es el propósito de esta técnica y qué puedes lograr con ella, identificando pues, si es lo que buscas o necesitas para tu proyecto. 

1. Minimizar los bugs 

Es uno de sus objetivos principales. 

La presencia de bugs en el desarrollo de software si bien no es absoluto en cuanto al fracaso, si que es una pérdida de tiempo y en ocasiones, de dinero. 

Ya que, no es lo mismo poder entregar un trabajo bien hecho y de calidad desde un principio sin errores o cuya presencia sea mínima, que tener que hacer cambios radicales desde el principio para que el producto final funcione correctamente. 

Por esta razón, uno de los mayores objetivos o propósitos de esta técnica de desarrollo, es precisamente prever esas situaciones en las que el código o el software en cuestión, pueda fallar de cara a sus funciones. 

Por ende, se plantean las posibles situaciones de fallo, y se crea el software con la finalidad de que pueda superar las pruebas de fallo.

2. Implementación de funciones justas 

Este punto también es muy importante de cara a la rentabilidad y utilidad del proyecto. 

Lo normal, es que los clientes establezcan los criterios y las necesidades que se tienen que tener en consideración durante el momento de diseño y planeación de la aplicación. 

De esta forma, se busca poder estudiar con exactitud, qué es lo que la aplicación software va a necesitar sin incurrir en faltas de funciones o sobre aplicarlas. 

Es decir, perder tiempo ideando un montón de funciones que con altas probabilidades, la mayoría de clientes o usuarios del software en cuestión, no utilizarán. 

Es por ello que es importante diseñar a partir de los requisitos y necesidades, y que el software se encargue de cumplir con dichos requisitos y satisfacer esas necesidades concretas, ni más ni menos. 

3. Desarrollo de un software actualizable 

Este objetivo o concepto es clave y básico en cualquier proceso de desarrollo de software, y con respecto al TDD no es la excepción. 

El desarrollo de aplicaciones, programas y cualquier proyecto ejecutable tiene que poseer la capacidad de ser modular y reutilizable en el tiempo. 

Es decir, poder realizar un mantenimiento del software y en caso de ser necesario, actualizarse a nuevas necesidades en el futuro.  

No tiene ningún sentido que un software en la actualidad, solo esté preparado para una única función o necesidad. 

Ya que estas características cambian con el tiempo y las necesidades comienzan a ser otras, por ende, un código tiene que poder ser capaz de actualizarse y adaptarse a las nuevas demandas del mercado. 

Esto hará que tu producto final sea mucho más profesional de cara a los clientes, y por supuesto, será mucho más eficiente. 

¿Por qué? Simple…

Tú imagina que un proyecto o software ha sido testeado previamente antes de la construcción de su código, como ocurre efectivamente en TDD. 

Pues bien, si el software al final funciona con normalidad y de manera exitosa, quiere decir que cualquier cambio a futuro que se le añada y no funcione, entonces el punto de partida comenzará en el nuevo código.

En pocas palabras, facilita el proceso de corrección, ya que todo lo que estaba escrito, está testeado y por ende, es correcto. 

Esto agiliza los procesos de cambio o actualización, incluso si se trata de otro desarrollador que no fue el creador per sé de la aplicación inicialmente.

I

¿Cómo funciona un TDD? 

Para entender un poco mejor cómo funciona esto de las pruebas antes de la escritura, es necesario comprender qué tipos de pruebas existen, que se definen a través de su complejidad. 

Es decir, imagina que posees una pirámide que está divida en tres partes desde su base, hasta la punta. La parte más baja de la pirámide, representa las pruebas básicas o unitarias, en el medio cuentas con las pruebas de integración, cuyo grado de dificultad es mayor ya que combinan distintos procesos y finalmente, las pruebas end to end que conforman la punta. 

1. End to End 

Son las pruebas de mayor dificultad en el ciclo de test de TDD, y por tanto a su vez, son las más lentas y costosas de realizar para un desarrollador ¿Y qué las hace tener estas características? 

Sencillo, son las que verifican el comportamiento total de la aplicación o software que se está desarrollando. Es decir, son las pruebas que verifican que una vez que se conocen todas las funciones que tendrá el software, todas las funciones se puedan ejecutar sin ningún tipo de problema, fallos o bugs. 

Dicho de otra manera, es la etapa que simula el nivel de uso de usuario. Es decir, el uso concreto que se le va a dar al software poniendo a prueba la integridad de datos, verificación y estabilidad del sistema y demás funciones o API ‘s. 

2. Integración 

Es la verificación y testeos de los elementos individuales como un todo que conforman el software. Es decir, todo lo que se desarrolló de forma independiente se le realiza una prueba para verificar que funciones bien todos los elementos y funciones juntos. 

Para ejemplificar esto, solo imagina un proyecto de desarrollo en el que las partes del software se dividieron en un equipo de trabajo. 

Entonces, mientras un miembro se encarga de desarrollar la base de datos, otro se encarga del modelo de negocio, backend, frontend, y así sucesivamente. 

Pues bien, todo esto se desarrolla por separado y luego se integra para comprobar que todo funcione bien. De eso se trata el test de integración, ya que si bien cada elemento del software por separado puede que funcione bien, no quiere decir que unido con lo demás, sí lo haga. 

3. Pruebas unitarias 

Son las pruebas más simples y a su vez, las más baratas de todas para un desarrollador. 

Y son las que pertenecen como tal al TDD. Ya que su propósito es verificar las partes mínimas de un software, como los componentes que lo van a conformar, sus clases o métodos a utilizar. 

Prescindir de este paso puede traer consigo una mayor cantidad de bugs, por lo que se perdería mucho más tiempo intentando identificar el problema y arreglando lo que sea necesario. 

¡Recuerda! Antes de realizar la integración de los componentes del software (funciones), es necesario constatar que cada componente por separado funcione correctamente y así descartar errores respectivos a futuro. 

Características de las pruebas unitarias en TDD 

En este pequeño apartado, la intención es poder mostrar cómo realizar una buena prueba unitaria, siguiendo los pasos necesarios para que la misma sea considerada como válida. 

Esto, además de representar para ti una guía, también habla muy bien de ti como profesional. 

• Se programan fácil y rápido

Si la escritura del código es muy amplia y puede que realizar una ejecución de una prueba te lleve todo un día, es un indicio de que tu código debería separarse en más partes. Ya que lo que identifica una prueba unitaria, es que además de programarse fácil, también debe ejecutarse fácil. 

El objetivo de estas pruebas es no restar agilidad y progresión a los proyectos, por ende, si se tarda mucho, quiere decir que hay que dividir las tareas. 

• No dependen de elementos externos 

Si cualquier prueba unitaria depende de una información o base de datos externa, quiere decir que no es una prueba unitaria como tal. Ya que es necesario que esta se pueda ejecutar de forma independiente.  

Es decir, dentro de la misma prueba unitaria, se deben encontrar todos los elementos necesarios para poder ejecutarse. 

• No deben depender de otras pruebas unitarias 

Parecido al punto anterior, pero visto desde los mismos elementos del software. Por ejemplo, imagina que posees 8 pruebas unitarias, y resulta que para ejecutar la prueba 7 necesitas que la 6 funcione correctamente, quiere decir que la prueba no está bien diseñada. 

La razón de esto es simple, imagina que cuando realizas la integración de las pruebas para ejecutarlas todas y conocer su funcionamiento acoplado, requieren ejecutar una prueba en concreto para saber si está funcionando bien. 

Pero a su vez, esta prueba necesita de otra para ejecutarse, entonces esto reducirá tu agilidad en el transcurso de tu proyecto. 

Pasos para realizar un TDD satisfactorio 

Si deseas poner en práctica el TDD, debes seguir los siguientes pasos que te mostrarán de forma clara qué es lo que debes tener en consideración. 

Paso 1: Escribir la prueba 

Definir cuál es la prueba que se utilizará para verificar la funcionalidad que quieras aplicar en tu software. 

Paso 2: Programar la funcionalidad 

Para este paso, es imperativo que puedas programar lo mínimo posible para que la prueba en cuestión pueda pasar y ser exitosa. 

A medida que el código se escribe, se realizan los test, la prueba puede llegar a tener múltiples fallos, pero lo ideal es poder realizarla y modificar el código hasta que la prueba sea exitosa. 

Paso 3: Mejorar el código (Refactoring) 

En el paso anterior definimos que las pruebas deben ser mínimas para que esta pueda ser positiva o pueda pasar efectivamente. Sin embargo, en este paso lo que se busca es pulir el código para que sea lo más estable y eficiente posible cada función. 

Para ello, tendrás a disposición en todo momento la prueba unitaria, que determinará si la prueba está resultando todo un éxito y puedes confiar en los resultados. 

Ahora que ya conoces a mayor profundidad sobre TDD, quisiéramos saber: ¿consideras que es un método o técnica efectiva en los proyectos de desarrollo de software? ¿Lo aplicarías o has aplicado en algún proyecto? 
Si para ti esta información te ha resultado útil, no olvides comentar y compartir.