Desarrollo orientado a los test

De ChuWiki

En el desarrollo software casi todo el mundo está de acuerdo en que hay que hacer test automáticos del software. Es decir, cuando construimos algo de software, debemos hacer otro software que verifique que el primero funciona bien. Si hacemos una clase, debemos hacer otra clase que prueba a la primera, que la instancie, llame a sus métodos con determinados parámetros conocidos y que compruebe que se devuelve el resultado esperado.

En el Desarrollo Orientado a Test -TDD o Test Driven Development- se va más allá. Todo el desarrollo debe orientarse a los test de la siguiente forma:


Escribir un test[editar]

Cuando queramos codificar en nuestro proyecto una nueva funcionalidad, lo primero que tenemos que hacer es una serie de clases de test que comprueben si nuestro código cumple o no esa funcionalidad.


Pasar los test y comprobar que uno falla[editar]

Después de escribir el test, pasamos TODOS los test disponible y comprobamos que sólo falla el que acabamos de escribir. Obviamente, debe fallar puesto que todavía no hemos implementado nuestra funcionalidad.


Implementar la funcionalidad[editar]

Ahora codificamos para que se cumpla la funcionalidad. Debemos codificar sólo para que se pase el test y sin preocuparnos demasiado de qué tal se integre el nuevo código en el ya existente. Lo importante es que el test se pase.


Pasar los test y comprobar que ninguno falla[editar]

Ahora volvemos a pasar TODOS los test y comprobamos que ninguno falla. La funcionalidad que queríamos implementar ya está implementada y funciona. Tampoco hemos estropeado nada que hubiera antes, puesto que los test anteriores también pasan.


Rehacemos el código[editar]

Ahora es el momento de rehacer el código para que lo que hemos añadido nuevo se integre perfectamente con lo que teníamos ya hecho. Evitar repeticiones de código, extraer partes comunes, etc, etc.


Volvemos a pasar los test y siguen sin fallar[editar]

Volvemos a pasar TODOS los test y comprobamos que después de rehacer el código, todo sigue funcionando como debe.


Repetimos[editar]

Llega el momento de repetir desde el principio con una nueva funcionalidad que queramos añadir.


Ventajas[editar]

Las ventajas de este tipo de desarrollo son:

  • Nos obliga a pensar la interface nuestros módulos antes de desarrollarlos. Puesto que escribimos el test antes, tenemos que pensar claramente qué va a hacer nuestro módulo. Es más, al hacer el código para poder pasarle un test automático, esto hace que el diseño en general sea mejor, más modular.
  • Todo el código tiene pruebas automáticas. Puesto que desarrollamos código para pasar el test, el test pasa por el código. No habrá código sin test.
  • Tenemos un punto claro en el que acabar de codificar, cuando se pasan los test. De esta manera se evita la siempre tentación de ir mejorando infinitamente y añadiendo funcionalidad que nadie ha pedido al código que estamos desarrollando.

Enlaces[editar]