- Define los requisitos de forma mucho mas exacta que un documento de texto.
- Una vez implementados el test y el software que cumple dicho test la automatización de las pruebas del software esta hecha también.
Parece ideal¿no? entonces ¿por que no se usa en todos los desarrollos? El gran problema es que un test automático (me refiero a un test que merezca la pena hacer) necesita que este muy "maduro" el desarrollo.
Pongamos, por ejemplo, una web de gestión de usuarios. Un test muy obvio es "alta de usuario" pero para dar de alta un usuario seguramente se necesite:
- Base de datos
- Validaciones
- Autorizaciones
- Etc..
Estos conceptos se deben definir desde el principio pero a alto nivel, si se intenta definir hasta el ultimo campo de la base de datos, hasta el ultimo método del fichero de codigo que implementa la validación, etc.. solo se conseguirá gasta mucho tiempo (y dinero) en una definicion que se va a cambiar seguro.
Entonces, debemos olvidarnos del TDD? La respuesta es no. Lo que se debe hacer es adoptar esta filosofia en una fase mas madura del desarrollo y tener en cuenta que se debe facilitar la adopción de esta filosofia en la filosofia que se use para empezar.
2 comentarios:
El uso de la filosifa TDD tiene implícito el uso del concepto de "Definition of done". La tarea esta hecha cuando cumple todos los test en los que esta implicada. Ademas, no solo es que tiene implícito el uso del concepto de "Definition of done", el concepto es cuantificable (no es algo conceptual como suele pasar en la mayoria de los desarrollos).
Consejo importante de como definir los test; Los test deben funcionar siempre es decir:
- No deben esperar un valor concreto (No vale esperar que este el Cliente "Pepito"). El test es para un conjunto de valores.
- Si el valor es de modificación entonces se debe hacer tambien la operación inversa. Es decir si se modifica el cliente "Pepito" a "Pepito1" entonces "el mismo test" debe hacer la operación de modificar el cliente "Pepito1" a "Pepito".
Publicar un comentario