Test-driven de­ve­lo­p­me­nt: así funciona este método

A medida que aumenta la co­m­ple­ji­dad de los programas in­fo­r­má­ti­cos, la me­to­do­lo­gía ágil del test-driven de­ve­lo­p­me­nt (TDD) se vuelve cada vez más popular. No es de extrañar, ya que el TDD permite a los pro­gra­ma­do­res ase­gu­rar­se de que no hayan quedado lagunas en el diseño de software antes de escribir el código fuente. De esta manera, no solo aumenta co­n­si­de­ra­ble­me­n­te la calidad del software final, sino que también se reducen los costes de ma­n­te­ni­mie­n­to.

El de­sa­rro­llo guiado por pruebas se usa, entre otros ámbitos, en la pro­gra­ma­ción extrema o extreme pro­gra­m­mi­ng, ca­ra­c­te­ri­za­da por las reviews, los test y el diseño y rediseño co­n­s­ta­n­tes. El test-driven de­ve­lo­p­me­nt también se ajusta a un ciclo de de­sa­rro­llo, que debe ser respetado para que la im­ple­me­n­ta­ción resulte eficaz.

Hace mucho que existen métodos variados para poner a prueba la calidad de los programas. Ya en los inicios del de­sa­rro­llo de software, la fu­n­cio­na­li­dad de los programas era evaluada en los de­pa­r­ta­me­n­tos de calidad por testers in­de­pe­n­die­n­tes. Por aquel entonces, el de­sa­rro­llo del software en sí y los pro­ce­di­mie­n­tos de prueba se co­n­si­de­ra­ban cue­s­tio­nes in­de­pe­n­die­n­tes. Esta pe­r­ce­p­ción cambió cuando Kent Beck, el de­sa­rro­lla­dor es­ta­dou­ni­de­n­se creador del extreme pro­gra­m­mi­ng, lanzó el concepto test first, que le dio la vuelta al orden de las tareas: en lugar de escribir primero el código fuente y luego ponerlo a prueba, el equipo de de­sa­rro­lla­do­res escribe primero los test y luego usa los casos de prueba para escribir e im­ple­me­n­tar el código de la mejor manera posible.

Si no se tienen muchos co­no­ci­mie­n­tos de de­sa­rro­llo de software, este proceso puede sonar co­n­trai­n­tui­ti­vo, pero efe­c­ti­va­me­n­te tiene mucho sentido y da mejores re­su­l­ta­dos. Mientras que los métodos de prueba co­n­ve­n­cio­na­les rea­li­za­dos a po­s­te­rio­ri aplican un modelo en cascada o en V, los procesos del TDD se de­sa­rro­llan en forma de ciclo. Más co­n­cre­ta­me­n­te, primero se ide­n­ti­fi­can a propósito los casos de prueba que suelen fallar, y luego se redacta úni­ca­me­n­te el código necesario para superar los test. Luego se re­fa­c­to­ri­zan los co­m­po­ne­n­tes: ma­n­te­nie­n­do las funciones, se amplía o se re­es­tru­c­tu­ra el código fuente, según sea necesario.

El test-driven de­ve­lo­p­me­nt se orienta según los re­su­l­ta­dos de los casos de prueba definidos por los de­sa­rro­lla­do­res. Su es­tru­c­tu­ra cíclica garantiza que el código se transmita al sistema pro­du­c­ti­vo úni­ca­me­n­te cuando se hayan cumplido todos los re­qui­si­tos del software. En otras palabras, los elementos del código se re­fa­c­to­ri­zan y se vuelven a poner a prueba tantas veces como sea necesario, hasta que el test ya no dé errores. Esta es­tra­te­gia permite en­ri­que­cer el software poco a poco con nuevas funciones, re­da­c­ta­n­do nuevo código fuente tras cada test superado. Por este motivo, el TDD se considera un modelo in­cre­me­n­tal de de­sa­rro­llo de software.

Cada test no suele tardar más de unos segundos o minutos en recorrer el ciclo, de manera que los re­su­l­ta­dos pueden ob­se­r­var­se rá­pi­da­me­n­te en el código pro­du­c­ti­vo. Para que las re­pe­ti­cio­nes puedan llevarse a cabo sin esfuerzo añadido, son ne­ce­sa­rios una he­rra­mie­n­ta y un framework de TDD. Los de­sa­rro­lla­do­res usan, por lo general, he­rra­mie­n­tas de au­to­ma­ti­za­ción del build, como Crui­se­Co­n­trol o Jenkins, que permiten integrar co­m­po­ne­n­tes en el código fuente de forma continua y sin fallos. Otros fra­me­wo­r­ks y tools populares en el de­sa­rro­llo con Java son JUnit, Maven y Ant. Por regla general, los test se redactan siempre en el mismo lenguaje de pro­gra­ma­ción que el código fuente. Para PHP existen, entre otras he­rra­mie­n­tas, Ceedling y CMock.

¿Y cómo se de­sa­rro­llan exac­ta­me­n­te los test? El ciclo que siguen los pro­gra­ma­do­res en el test-driven de­ve­lo­p­me­nt también recibe el nombre de red-green-refactor y describe cada una de las fases que deben cumplirse para alcanzar una mayor efi­cie­n­cia:

1. Fase roja (red phase): en esta fase hay que ponerse en los zapatos del usuario, que quiere poder usar el código de forma sencilla. Se redacta, por lo tanto, un test que contenga co­m­po­ne­n­tes que aún no hayan sido im­ple­me­n­ta­dos, para luego decidir qué elementos son realmente ne­ce­sa­rios para que el código funcione.
2. Fase verde (green phase): su­po­nie­n­do que el test falle y se marque en rojo, se adopta entonces el papel de pro­gra­ma­dor y se intenta encontrar una solución simple. Es muy im­po­r­ta­n­te redactar úni­ca­me­n­te la cantidad de código que sea necesaria. El código redactado se integra luego en el código pro­du­c­ti­vo, de forma que el test quede marcado en verde.
3. Re­fa­c­to­ri­ng: en este paso, el código pro­du­c­ti­vo se pasa a limpio y se pe­r­fe­c­cio­na su es­tru­c­tu­ra. Podría decirse que ahora se completa y re­es­tru­c­tu­ra de manera que resulte elegante y co­m­pre­n­si­ble para los de­sa­rro­lla­do­res. Entre otras cosas, se eliminan los du­pli­ca­dos en el código, y se vuelve más pro­fe­sio­nal.

Hay que tener en cuenta que las tareas no se solapen entre ellas, es decir, que no se redacten test en las fases 2 y 3 ni se escriba código pro­du­c­ti­vo en las fases 1 y 3.

El test-driven de­ve­lo­p­me­nt es una me­to­do­lo­gía de diseño de software que se basa en test o pruebas para guiar el proceso. Al contrario de lo que ocurre en me­to­do­lo­gías que posponen los test a un punto ulterior, los casos de prueba en TDD se realizan al inicio del proceso de diseño. Los test que se utilizan en esta me­to­do­lo­gía difieren en cuanto a propósito y alcance: el más sencillo es el test de módulos o unit test. Con él se prueban los co­m­po­ne­n­tes in­di­vi­dua­les de un programa in­fo­r­má­ti­co. Otros test más complejos son las pruebas fu­n­cio­na­les y de in­te­gra­ción, que examinan la in­ter­ac­ción entre las distintas partes del sistema y la fu­n­cio­na­li­dad del software en conjunto.

A partir del TDD se de­sa­rro­lló, hace unos años, el behavior-driven de­ve­lo­p­me­nt (BDD) o, en español, el de­sa­rro­llo guiado por co­m­po­r­ta­mie­n­to. Esta me­to­do­lo­gía no se guía ini­cia­l­me­n­te por la ade­cua­ción del código, sino por el co­m­po­r­ta­mie­n­to que desea ob­se­r­var­se en el software. Una de las ventajas de esta es­tra­te­gia es que no requiere co­no­ci­mie­n­tos es­pe­cia­li­za­dos de co­di­fi­ca­ción para es­pe­ci­fi­car los casos de prueba deseados, lo cual permite in­co­r­po­rar en el proceso de de­sa­rro­llo a gestores de calidad y a otras partes in­te­re­sa­das. De forma general, puede decirse que el BDD es el mejor método a la hora de diseñar pruebas, mientras que el TDD da como resultado una ar­qui­te­c­tu­ra más limpia.

La tabla siguiente resume las ventajas e in­co­n­ve­nie­n­tes del de­sa­rro­llo guiado por pruebas:

Aunque los distintos métodos de prueba pueden im­ple­me­n­tar­se uno a uno, aplicando una co­m­bi­na­ción de métodos basados en pruebas y en co­m­po­r­ta­mie­n­to se obtiene un software de mayor calidad, que también pro­po­r­cio­na mayor sa­ti­s­fa­c­ción al cliente.