Test Driven Development (Desarrollo Dirigido por Tests)

Es una tcnica de diseo e implementacin de software incluida dentro de la metodologa XP

TDD es una tcnica para disear software que se centra en tres pilares fundamentales:

La implementacin de las funciones justas que el cliente necesita y no ms

Evitamos desarrollar funcionalidad que nunca ser usada.

La minimizacin del nmero de defectos que llegan al software en fase de produccin.

La produccin de software modular, altamente reutilizable y preparado para el cambio.

No se trata de escribir pruebas a granel como locos, sino de disear adecuadamente segn
los requisitos.
Pasamos, de pensar en implementar tareas, a pensar en ejemplos certeros que eliminen la
ambigedad creada por la prosa en lenguaje natural nuestro idioma).
Razones por la cuales usar TDD segn Kent Beck (uno de los padres de la metodologa XP)

La calidad del software aumenta (y veremos por qu).

Conseguimos cdigo altamente reutilizable.

El trabajo en equipo se hace ms fcil, une a las personas.

Nos permite confiar en nuestros compaeros aunque tengan menos experiencia.

Multiplica la comunicacin entre los miembros del equipo.

Las personas encargadas de la garanta de calidad adquieren un rol ms inteligente e

interesante.

Escribir el ejemplo (test) antes que el cdigo nos obliga a escribir el mnimo de
funcionalidad necesaria, evitando sobre disear.

Cuando revisamos un proyecto desarrollado mediante TDD, nos damos cuenta de que los
tests son la mejor documentacin tcnica que podemos consultar a la hora de entender
qu misin cumple cada pieza del puzzle.

Incrementa la productividad.

Nos hace descubrir y afrontar ms casos de uso en tiempo de diseo.

La jornada se hace mucho ms amena.

Uno se marcha a casa con la reconfortante sensacin de que el trabajo est bien hecho.

No es una varita mgica y no dar el

mismo resultado a un experto arquitecto de software que a un programador junior que

est empezando. Sin embargo, es til para ambos y para todo el rango de integrantes
del equipo que hay entre uno y otro.

El algoritmo TDD slo tiene tres pasos:

Escribir la especificacin del requisito (el ejemplo, el test).

Implementar el cdigo segn dicho ejemplo.

Refactorizar para eliminar duplicidad y hacer mejoras.

Una vez que tenemos claro cul es el requisito, lo expresamos en forma de cdigo.

Lo haremos con algn framework xUnit. Cmo escribimos un test para un cdigo que
todava no existe?

Un test no es inicialmente un test sino un ejemplo o especificacin.

Un test se puede modificar.

Para poder escribirlo, tenemos que pensar primero en cmo queremos que sea la API, es
decir, tenemos que trazar antes de implementar.

Escribir la especificacin primero

Tenemos que hacer el esfuerzo de imaginar cmo seria el cdigo como si ya estuviera
implementado y cmo comprobaramos que, efectivamente, hace lo que le pedimos que
haga.

Implementar el cdigo que hace funcionar el ejemplo

Codificamos lo mnimo necesario para que se cumpla, para que el test pase.

El mnimo cdigo es el de menor nmero de caracteres porque mnimo quiere decir el que
menos tiempo nos llev escribirlo.

No importa que el cdigo parezca feo o chapucero, eso lo vamos a enmendar en el

siguiente paso y en las siguientes iteraciones.

La mxima es no implementar nada ms que lo estrictamente obligatorio para cumplir la

especificacin actual.

No se trata de hacerlo sin pensar, sino concentrados para ser eficientes.

Refactorizar

Segn Martn Fowler, refactorizar10 es modificar el diseo sin alterar su comportamiento.

Rastreamos el cdigo (tambin el del test) en busca de lneas duplicadas y las eliminamos
refactorizando.

Revisamos que el cdigo cumpla con ciertos principios de diseo (S.O.L.I.D) y

refactorizamos para que as sea.

Los IDE como Eclipse, Netbeans o VisualStudio, son capaces de llevar a cabo las
refactorizaciones ms comunes.

In
icial

La clave de una buena refactorizacin es hacerlo en pasitos muy pequeos.

Se hace un cambio, se ejecutan todos los tests y, si todo sigue funcionando, se hace otro
pequeo cambio.

Signifi
cado
(acrnimo)

Concepto

Principio de nica Responsabilidad (Single responsibility principle)la nocin de que un objeto

S

SRP
solo debera tener una nica responsabilidad.
Principio Abierto/Cerrado la nocin de que las entidades de software deben estar abiertas

OCP
para su extensin, pero cerradas para su modificacin.
Principio de sustitucin de Liskov la nocin de que los objetos de un programa deberan ser

LSP

reemplazables por instancias de sus subtipos sin alterar el correcto funcionamiento del programa.
Ver tambin diseo por contrato.
Principio de Segregacin de la Interface (Interface segregation principle) la nocin de que

ISP
muchas interfaces cliente especficas son mejores que una interfaz de propsito general.

Principio de Inversin de Dependencia (Dependency inversion principle) la nocin de que uno

D

DIP

debera Depender de Abstracciones. No depender de concreciones.

La Inyeccin de Dependencias es uno de los mtodos que siguen este principio.

ljg
Y TDD sirve para proyectos grandes?
Un proyecto grande no es sino la agrupacin de pequeos sub proyectos y es ahora cuando toca
aplicar aquello de divide y vencers.
La clave est en saber dividir, en saber priorizar.
De ah la ayuda de Scrum para gestionar adecuadamente el backlog del producto.