TDD es una práctica de programación que se basa en escribir las pruebas primero y después realizar el desarrollo.
Para realizar esta práctica se suelen utilizar pruebas unitarias y es tan sencillo como que al lanzar la prueba, esta falla. Tras ese fallo, se implementa el código para verificar que esta prueba funciona perfectamente.
La idea de esta técnica es que el desarrollador pueda hacer un código limpio y que, cuando todas las pruebas estén cubiertas y en OK, el software garantiza que se han establecido todos los requisitos solicitados. Una vez que las pruebas están OK habrá que refactorizar para eliminar código sobrante o duplicado.
Al parecer una de las principales ventajas es que no se necesitaría la utilización de debugger y que al avanzar en pequeños pasos, permite al programador centrarse en tareas muy concretas y actuales para acabarla más satisfactoriamente. Otra ventaja es que el código ya está cubierto desde el inicio por pruebas.
Las principales limitaciones que presenta el TDD es su utilización en GUIs, objetos distribuidos y bases de datos.
Mi opinión está justo en medio de esta técnica, ni la defiendo ni la rechazo, la veo que tiene ciertas ventajas a la hora de hacer un desarrollo más limpio, pero también veo que ni es necesario tener un 100% de cobertura de pruebas unitarias y que cualquier cambio en el código por mínimo que sea, romperían los test y habría que estarlos manteniendo constantemente, duplicando el trabajo, y si los test están rotos, los bugs florecerán como la espuma.
El programador tendrá un código limpio, facilidad para realizarlo y una ayuda extra que le será muy útil, pero también basará el desarrollo en esas pruebas y quizá habrá algo que se escapa, que surge más adelante (nunca jamás desde el inicio acaban saliendo absolutamente todos los caminos posibles en una pantalla, somos humanos y siempre hay que añadir algún caso de prueba posterior) y que puede romper la aplicación en cualquier momento, personalmente yo pienso que el desarrollo debe decidir las pruebas no al contrario, como bien explica la frase: “como puedo hacerlo más claro, no como puedo hacerlo más testeable“. Al fin y al cabo el TDD produce un sobre testing y es preferible, desde mi punto de vista, automatizar las pruebas de regresión.
Una ventaja del TDD es la seguridad que aporta, la cobertura total del código y que todo está absolutamente probado, por lo tanto todos los desarrollos que utilicen esta técnica serán mucho más fiables y casi al 100% no fallarán.
Pienso que para un buen uso del TDD el desarrollador tiene que confiar ciegamente en las pruebas, absolutamente tanto como para hacer una subida a producción dependiendo exclusivamente del correcto resultado de estos test.
Desde el punto de vista de un tester, esta técnica no debería de gustar, primero porque la persona que desarrolla realiza las pruebas. Un desarrollador que se lee un requisito o especificación y lo interpreta incorrectamente, generará errores en todos sus test, lo cual acabará siendo una pérdida de tiempo y de dinero.
El TDD necesita un tiempo de desarrollo mayor, esto afectará a los entregables, a los usuarios, a los directivos que quieren ver resultados rápidamente…y quizá se realizaron infinidad de test innecesarios que después desaparecerán al refactorizar el código, al fin y al cabo, los test funcionales son los más importantes y los que deben de hacer que un desarrollo pase o no a producción.
Creo que la técnica de TDD debería de utilizarse en un pequeño reducto dentro de una metodología ágil, nunca extendiendo todo el desarrollo a esta, el tester debería de crear una batería de pruebas antes del desarrollo, el desarrollador basar sus pruebas unitarias a estos casos de prueba y después basar el desarrollo a todo lo demás, pasando, una vez finalizado, toda la batería de pruebas y completando el ciclo completo de testing habitual en la metodología en la que se base el proyecto. De esta manera el desarrollador generará un código más limpio y a su vez será validado como siempre.
?){kind=link}
0 Comentarios