TEST DRIVEN DEVELOPMENT
INTRODUCCIÓN
Según el Desarrollo Guiado por Pruebas o Test Driven Development, en inglés, es el programador quien realiza las pruebas de unidad de su propio código, e implementa esas pruebas antes de escribir el código a ser probado.
Cuando el programador recibe el requerimiento de implementar una parte del sistema, y una vez que comprendió cuál es la funcionalidad pretendida, debe empezar por pensar qué pruebas va a tener que pasar ese fragmento de programa (o unidad) para que se considere correcto. Luego procede a programar, pero no el código de la unidad que le tocó, sino el código que se va a encargar de llevar a cabo las pruebas. Cuando está satisfecho de haber escrito todas las pruebas necesarias (y no antes), comienza a programar la unidad, con el objetivo de pasar las pruebas que programó.
La forma de trabajo del programador también cambia mucho durante la escritura del código funcional propiamente dicho. En lugar de trabajar durante horas o días hasta tener la primera versión en condiciones de ser probada, va creando pequeñas versiones que puedan ser compiladas y pasen por lo menos algunas de las pruebas. Cada vez que hace un cambio y vuelve a compilar, también ejecuta las pruebas de unidad. Y trata de que su programa vaya pasando más y más pruebas hasta que no falle en ninguna, que es cuando lo considera listo para ser integrado con el resto del sistema.
CARACTERÍSTICAS
Una ventaja de esta forma de programación es el evitar escribir código innecesario ("You Ain't Gonna Need It" (YAGNI)). Se intenta escribir el mínimo código posible, y si el código pasa una prueba aunque sepamos que es incorrecto nos da una idea de que tenemos que modificar nuestra lista de requerimientos agregando uno nuevo.
La generación de pruebas para cada funcionalidad hace que el programador confíe en el código escrito. Esto permite hacer modificaciones profundas del código (posiblemente en una etapa de mantenimiento del programa) pues sabemos que si luego logramos hacer pasar todas las pruebas tendremos un código que funcione correctamente.
Otra característica del Test Driven Development es que requiere que el programador primero haga fallar los casos de prueba. La idea es asegurarse de que los casos de prueba realmente funcionen y puedan recoger un error.
DESARROLLO
La metodología TDD, a grandes rasgos, se basa en lo siguiente:
- Se construyen las pruebas unitarias (o se puede extender si se desea el concepto a otros tipos de pruebas de más alto nivel, siempre y cuando sea automatizable su ejecución).
- A continuación se construye el componente software que debe verificar las reglas de funcionamiento definidas en las pruebas.
- Una vez que se tiene un software que verifica las pruebas implementadas, se procede a su refactorización.
VENTAJAS
-En ocasiones contadas, los programadores necesitarán ejecutar el depurador o debugger.
-Produce aplicaciones de mayor calidad en un tiempo menor, a pesar de los elevados requisitos iniciales.
-Permite que el programador se centre en la tarea actual y como objetivo hacerla pasar las diferentes pruebas establecidas.
-Da confianza a los programadores en su código, ya que habrá pasado por las pruebas.
LIMITACIONES
-Complejidad a la hora de automatizar las pruebas.
-Es difícil el uso de esta metodología en situaciones en las que requieren pruebas completas de funcionalidad del sistema.
-Es muy importante diseñar y codificar test de bajo y fácil mantenimiento.
-Las pruebas en el desarrollo de software tienen una menor importancia que el desarrollo o arquitectura de software, pero son fundamentales.
CONSLUSIONES Y OPINIÓN PERSONAL
Una de las grandes diferencias con el estilo de trabajo tradicional es que ya no compite con otro u otros, sino que compite consigo mismo; se enfrenta al desafío de escribir código que pase las pruebas que él mismo programó. Y siguiendo las premisas de muchos de los métodos ágiles, solamente programará lo que sea estrictamente necesario para ese fin.
La ventaja de desarrollar las pruebas antes de implementar los componentes es la indicada en el párrafo anterior, es decir, enfrentarse y comprender el problema antes de empezar a resolverlo. Si las pruebas unitarias se construyen después, no estaríamos hablando de TDD, eso es importante, por lo que lo repito, si las pruebas unitarias se construyen después se trata de otra estrategia de desarrollo de software, no de desarrollo guiado por las pruebas.
Se sabe que cuanto más tarde se detecten los errores más esfuerzo se requiere para solucionarlo, esta técnica pretende disminuir el riesgo por la presencia de errores de ese tipo, además de facilitar un código donde sea mucho más fácil trabajar, tanto para corregir esas incidencias como para construir nuevas funcionalidades o modificar, si fuera necesario (el software es de naturaleza adaptativa), las ya implementadas.
REFERENCIAS UTILIZADAS
PREGUNTAS:
1. ¿Cuál de estas reglas se incluye en Test Driven Development?:
a) Se deben evitar las pruebas automáticas, ya que no nos aportan suficiente información de los fallos.
b) No se puede escribir más código productivo del estrictamente necesario para hacer pasar un test.
c) Los errores de compilación no se consideran fallos.
d) Las pruebas unitarias deben de ser lo mas grande posible para ahorrar futuras pruebas.
2. En el TDD, ¿qué afirmación es falsa?:
a) El uso de las base de datos hace que las pruebas sean menos costosas.
b) Se intenta escribir el mínimo código posible.
c) La generación de pruebas para cada funcionalidad hace que el programador confíe en el código.
d) Se requiere que el programador primero haga fallar los casos de prueba.
3. Según el TDD, ¿quién es el encargado de realizar las pruebas unitarias?
a) Gerente del proyecto.
b) Product Owner.
c) Coordinador técnico.
d) El propio programador.
4. ¿Cómo se puede abreviar el ciclo de vida del TDD?
a) Refactor-rojo-verde (haciendo referencia a hacer un refactor, a fallar un test y hacerlo pasar).
b) Rojo-refactor-verde (haciendo referencia a fallar un test, hacer un refactor y hacerlo pasar).
c) Rojo-verde-refactor (haciendo referencia a fallar un test, hacerlo pasar, y hacer un refactor).
d) Verde-rojo-refactor (haciendo referencia a hacer pasar un test, fallar el test y hacer un refactor).
5. ¿Cúal de las siguientes disciplinas no pertenece al ciclo de vida del TDD?
a) Escribir una prueba
b) Elegir un requisito
c) Definir la lista de requisitos
d) Ejecutar las pruebas automatizadas
6. ¿De qué metodología evolucionó el TDD?
a) Scrum
b) XP
c) RUP
d) DSDM
7. Tras generar las pruebas e implementarlas, el programador:
a) Comienza la programación de la solución, y no se prueba hasta que no está generado todo el programa en sí.
b) Debe esperar a que el cliente de el visto bueno a los test generados.
c) Se programa la funcionalidad con vistas a fallar en las pruebas, para así saber que son correctas.
d) Juntan todas las pruebas para hacer un gran test a pasar posteriormente.
8. ¿Cual de las siguientes afirmaciones NO es correcta?
a) Como los programadores hacen pruebas que les imponen sus compañeros y el cliente, el código que surge es más robusto.
b) Aunque inicialmente en el TDD hay que crear muchas pruebas antes de comenzar la implementación final, se hace un desarrollo más rápido.
c) Uno de los objetivos es intentar escribir la mínima cantidad de código posible.
d) Las pruebas unitarias son obligatorias y una funcionalidad no se da por acabada hasta que las pase.
