Sólo hay que hacer una busqueda en google para encontrar cientos de artículos sobre “Test-Driven Development“. Si nunca has oido hablar de este concepto, el TDD (Test-Driven Development) se define a la técnica por la cual las pruebas se han de escribir siempre antes de que se escriba una sola línea de código.
No debemos olvidar por tanto que este tipo de pruebas son llevadas a cabo por el equipo de desarrollo y no por el equipo de testing. Esta técnica no sustiturá las pruebas funcionales, de rendimiento, o de automatización…sino que complementará a las pruebas realizadas por el departamento de testing. El objetivo principal es obtener código limpio que funcione.
En que consiste el TDD:
1) Primero escribimos las pruebas y las ejecutamos. Por lo tanto todas nuestras pruebas fallarán porque aún no se ha comenzado a codificar.
2) Comenzamos a codificar para pasar esas pruebas que hemos diseñado.
3) Cuando hayamos terminado la implementación todas las pruebas habrán pasado satisfactoriamente.
4) Comienza el “refactoring” del código, con el fin de mejorarlo.
Estos sería a grandes rasgos los pasos principales del TDD. ¿Cuales son sus beneficios?:
- El código estará siempre asociado a algún prueba (test case).
- Las pruebas siempre estarán junto al código.
- Las prueban nos servirán para comentar el código.
- Nos permite mejorar el codigo mediante el “refactoring”.
- El código habrá sido probado antes de llegar a los equipos de testing. Lo cual garantiza estabilidad.
Referencias:
- StickyMinds.com, Jeff Patton
Garantizar estabilidad del sistema o módulo del proyecto es una necesidad básica. Pero en proyectos del día a día (lanzamiento de versiones contantes por temas ajenos a la empresa. ej. cambios legales) es complicado “obligar” al equipo de desarrollo que ejecuten unas pruebas antes de entregarnos la versión, aunque luego el resultado nos de la razón: INESTABILIDAD DEL SISTEMA (con el coste que ello conlleva).
La responsabilidad de todo QA responsible debe ser la correcta aplicación en el proceso de entrega de versiones, junto a un plan de pruebas mínimo exigido al equipo de desarrollo.
Esta técnica esta muy extendida en equipo de desarrollo que hacen eXtreme Programming…como tu bien dice, por lo aprepado de las entregas se espera por lo menos que se pasen unas pruebas mínimas. Nosotros siempre hemos hecho “Smoke Tests” que marcarán los criterios de comienzo de las pruebas.