Test Driven Development: Conceptos

Entre la maraña de metodologías ágiles de desarrollo de proyectos software, se encuentra esta metodología, propuesta por Kent Beck (Extreme Programming, entre otras metodologías ágiles, toda una eminencia en este campo). En los siguientes artículos desarrollaré los conceptos de esta técnica y los patones asociados a la filosofía TDD. Espero que a alguien le resulte útil.

Conceptos

Test-Driven Development se basa en dos máximas:

  1. escribe código nuevo solamente si tienes primero un test automático que falla; y
  2. elimina la duplicación.

Esto implica:

  • Diseñar organizadamente, haciendo que el código que funciona retroalimente las nuevas decisiones de diseño.
  • Escribir tus propios tests, ya que no puedes esperar a que lo haga otro por tí.
  • El entorno de desarrollo debe proveer de respuestas rápidas a pequeños cambios.
  • Tus diseños deben consistir en componentes fuertemente cohesionados y débilmente acoplados para poder probarlos fácilmente.

El “mantra” TDD establece cómo escribir los test en tres fases: rojo-verde-refactor.

  1. Rojo: escribe un test rápidamente, pequeño, que quizá ni funcione ni compile.
  2. Verde: haz que el test funcione rápidamente, cometiendo los errores de diseño que sean necesarios en el proceso. Tu obsesión: la barrita verde que significa que el test ha pasado.
  3. Refactor: elimina errores de diseño introducidos.

TDD trata de acometer el miedo a no ver el final de un proyecto, reconduciéndolo a un “¡ten cuidado!, mejor vamos paso a paso”. El miedo conduce a tomar soluciones tentativas, a comunicarse menos, impida la retroalimentación en el desarrollo y te convierte en un gruñón. Cada paso que se da debe asegurarte sobre tu posición para tomar impulso hacia el siguiente paso. Al final, el desarrollo debe convertirse en una secuencia de pasos seguros. Kent Beck pone un ejemplo muy bueno para entender el proceso de TDD: imaginemos que tenemos que sacar agua de un pozo. Podemos utilizar una polea lisa y tirar de la cuerda sin soltar hasta que el cubo sale completamente. Utilizar TDD en este proceso equivaldría a utilizar una rueda dentada que nos permite siempre avanzar pasito a pasito, estar sobre seguro, de manera que si en cualquier momento soltamos la cuerda el cubo no se precipita de nuevo al vacío y no hay que volver a empezar. Cada paso que se da se sustenta en la seguridad del paso anterior.

TDD tiene como limitación el que no permite asegurar objetivos de seguridad y concurrencia. Simplemente no sirve.

Procedimiento: 1º se escribe el test; 2º se escribe el código. ¿cómo?

  1. Añade rápidamente un test, sin preocuparte por el diseño.
  2. Ejecuta todos los test y observa cómo el test falla.
  3. Cambia el código del test para que pase.
  4. Ejecuta todos los test y observa como todos los tests pasan.
  5. Refactoriza e ltest para eliminar la duplicación y mejorar su diseño.

Consejos:

  • Empieza probando lo más básico y sencillo.
  • La duplicación de código es el síntoma de que hay dependencias que eliminar.
  • Comienza pensando qué cosas hay que probar; haz una lista e implementa un test para cada elemento de la lista. Ocurrirá que, a medida que implementas los tests, se te ocurrirán nuevos test; con lo cual la lista es dinámica.
  • Si en un determinado momento no sabes cómo acometer el siguiente paso, no lo des: divide dicho paso en otros más sencillos y impleméntalos uno a uno. Si el siguiente paso (o los siguientes pasos) son intuitivamente sencillos, puedes juntarlos y dar un paso más grande. El tamaño del paso a dar no es estático, sino adaptable a la información que tenemos, al riesgo y a la sencillez del paso a dar.

Para implementar la técnica de TDD de forma efectiva los test tienen que tener dos características fundamentales:

  • los test tienen que pasar rápidamente, o no se pasarán con la frecuencia apropiada que dicta el método.
  • los test tienen que estar aislados totalmente entre sí; el resultado de uno no debe jamás afectar a otro test, o de lo contrario no servirán para nada porque pueden dar una falsa sensación de seguridad.

He tratado de ser lo más esquemático posible para que se entiendan bien las ideas. En siguientes entregas explicaré brevemente algunos patrones relacionados con la metodología de Test-Driven Development (¿se entiende ahora lo de desarrollo dirigido por pruebas?).


Referencias:

“Test-Driven Development by Example
Kent Beck

6 pensamientos en “Test Driven Development: Conceptos

  1. Buen post. Lo unico que queda un poco raro es lo de que TDD no sirve para seguridad. Estoy de acuerdo en que no va bien para concurrencia pero a que te refieres con seguridad?

    Gracias🙂

  2. Kent Beck se refiere a que las técnicas de TDD no permiten asegurar los objetivos de seguridad de un proyecto. Aunque no se explaya mucho más en este punto (básicamente lo cita y nada más), creo que se refiere a objetivos de autenticación de usuarios, ACL’s, acceso a objetos, protocolos de seguridad tipo HTTPS u otros basados en SSL.

  3. De acuerdo, en cuanto pueda, si me acuerdo, reviso dónde decía esto el autor a ver si puedo explicarme un poco mejor en ese punto, porque realmente no concretaba mucho en ese aspecto.

    Por cierto, muchas gracias por visitarme; sé que estuviste hace poco dando un curso sobre TDD para el colegio de informáticos de Castilla y León, un compañero de mi trabajo estuvo allí. Muchos quisimos ir, pero se decidió que fuera él. Por cierto, creo que tiene pendiente una charla para contarnos qué aprendió…😛

  4. Pingback: Test Driven Develpment: Patrones (I) « Realizando la idealidad

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s