Esta metodoogía de trabajo, llamada TDD, que está tan de moda, que es como la canción del verano, como minimo, hemos oido hablar de ello. Pero, ¿En que consiste TDD?
Desde donde yo lo veo, TDD, es una metodologia de trabajo, para el desarrollo de aplicaciones, en la que se pretende conseguir, que todo desarrollo que se haga este siempre, probado, es decir, que para cada paso que se da, en el avance de un desarrollo, ya se tengan las pruebas del mismo implementadas.
Por eso decimos que es un desarrollo orientado a pruebas, poruqe son estas las que marcan el camino a seguir del desarrollo, hago una función que tiene que sumar, y compruebo que suma, me da igual su integración, tengo qeu comprobar que suma, y que lo hace bien en todos los casos, cuando hay número negataivos, positivos y ceros, en ambos lados de la suma y si alguien intenta usar letras o simbolos?, pues también habrá que tenerlos en cuenta. A esto se llaman, pruebas unitarias, compruebo que la acción aislada se ejecuta correctamente.
Sobre todo se pretende con este sistema, que se cierren ciclos con funcionalidades completas, que el cliente de la aplicación pueda ver, de esta forma, se van enseñando las partes que se terminan, dando por buena, la frase: "el software que funciona es la principal medida de progreso"
TDD consiste en definir una "prueba" por cada requisito que debe cumplirse en un desarrollo, de tal forma que al cumplir cada uno de ellos, se vaya cumpliendo cada requisito
Pero TDD no es solo una metodología que nos indica que debemos probar, y como, sin oque además auna una serie de buenas practicas y consejos, que al aplicarlos, se hace el desarrollo más ágil. Estas técnicas pretenden ayudar a los desarrolladores aumentando su productividad y velocidad en el desarrollo, además de combatir el denominado "codigo sucio", que hace ininteligible el codigo fuente.
Algunas ideas para empezar a orientarse en esta forma de trabajo.
1. Nombres de las variables, no vale cualquiera, siempre es mejor que tenga sentido, no llames "cxdmbvar" a una variable.
2. Lo,mismo para los métodos.
3. Las pruebas dirigen, si no pasa la prueba. No esta desarrollado.
4. Se aconseja el uso de asserts para la comprobación es las pruebas, así lo puedes retirar cuando pase a producción.
5. Aunque parezca raro, la prueba es lo primero que se escribe, el codigo se va escribiendo según necesitamos para satisfacer la prueba.
6. TDD es muy costoso al principio, hace falta tiempo y dedicación para que se noten sus efectos.
No hay comentarios:
Publicar un comentario