Test Driven Development: Patrones (I)

Después de estudiar las generalidades de Test Driven Development, explicaremos brevemente en una serie de artículos los patrones incluídos por Kent Beck relacionados con TDD:

Patrones generales

Test n

No es lo mismo probar algo a mano que ejecutar tests automáticos. Éstos últimos son una garantía de que lo que se ha cambiado no ha roto nada. Cuando hay estrés y el tiempo apremia, más razón hay para ejecutar los tests más a menudo en cada pequeño cambio.

Test aislado

Los tests tienen que ejecutarse lo más rápidamente posible, para no perder tiempo y para poder ejecutarlos con la frecuencia adecuada. Además, es muy importante que el estado de cada test debe ser totalmente independiente y no afectar a los demás.

Lista de tests

Antes de empezar a escribir tests, haz una lista (dinámica) de las cosas que se te ocurran que hay que probar. A medida que escribas cada uno de dichos tests pueden aparecer nuevos casos a probar que se añadirán a la lista. Recuerda que cada test debe probar una cosa y ser lo suficientemente pequeño como para dar un pequeño paso seguro adelante, que te permita avanzar hacia el estado final que deseas. Puesto que lo primero a lograr es un test que funcione, añade a la lista las refactorizaciones que se van a necesitar una vez se ha conseguido escribir un test que pasa.

El test lo primero

Primero escribe el test y después escribe el código probado por el test.

Los asertos, primero

Antes de escribir el código del test escribe los asertos; así sabrás de antemano las condiciones que se deben dar durante el desarrollo del test; de modo que el modelo a seguir es: test guiados por asertos. Cuando te dispongas a escribir el test, hazte las siguientes preguntas:

  • ¿De qué tipo de código se trata? ¿Es una modificación / nuevo método / nueva clase / refactor / … ?
  • ¿Cómo deberían ser los nombres de clases, variables y métodos?
  • ¿Cómo vas a comprobar el resultado correcto?
  • ¿Cuál es el resultado correcto?
  • ¿Qué otros tests nuevos sugiere este test?

Probar los datos

Utiliza datos lo más simples posible para tus test; recuerda que los leerán personas, así que si ‘1’ y ‘3’ valen igual para probar el caso, usa ‘1’. No reutilices la misma constante o variable para significados diferentes. Esto es válido salvo que se trata de tests de rendimiento o de sistemas en tiempo real. En estos casos deben utilizarse datos realistas.

Datos evidentes

Representa claramente los resultados esperados y reales y haz que la comparación entre ellos sea explícita.

Patrones de barra roja

Los siguientes patrones se refieren al desarrollo de tests en la fase en la cual el test falla.

Test de un sólo paso

Elige un test de la lista de tests pendientes que te vaya a enseñar algo del sistema y que estés convencido de poderlo implementar. Cada test debe representar un paso adelante hacia el objetivo global. Si no encuentras en la lista ningún test que represente un paso adelante, añade nuevos tests que representen un acercamiento a los elementos que ya tienes en la lista.

Al final no se sigue un desarrollo top-down o bottom-up, sino más bien de lo conocido a lo desconocido: tomando piezas de las que tenemos conocimiento, vamos avanzando hacia lo desconocido del sistema, aprendiendo cosas de éste en el camino.

Test de comienzo

¿Con qué test comenzar? Con una variante de una operación que no haga nada.

Tests de explicación

¿Cómo se propaga el uso de testing automático? Pide y provee explicaciones en forma de tests. De este modo, el equipo adoptará TDD más fácilmente. Convierte, por ejemplo, diagramas de secuencia en tests.

Test de aprendizaje

Escribe tests para comprender el funcionamiento de un nuevo API, COTS, librería, etc. que vayas a utilizar. Puede crearse, así, un modo de trabajar que es: si los tests pasan, ejecuto la aplicación; si no, no; porque sé que no va a funcionar de ninguna manera.

Otro test

¿Cómo mantener una discusión técnica sin salirse del tema? Cuando surja una idea que toque de algún modo la discusión principal, añade un test a la lista, y vuelve al tema de discusión. Mantente centrado en los objetivos, pero receptivo a nuevas ideas; anótalas y vuelve a tus objetivos.

Test de regresión

En cuanto se detecta un error, se escribe un test que lo cubra y después se soluciona el problema. Los tests de regresión son tests que, de haber tenido un conocimiento más profundo del sistema, cuando la funcionalidad que ha fallado se estaba desarrollando, debería haberse escrito en tal momento. Cada vez que escribas un test de regresión, piensa qué hubieras necesitado saber para haber escrito dicho test en primer lugar, cuando desarrollaste esa funcionalidad.

Descanso

¿Qué haces cuando estás cansado o te encuentras atascado? Tómate un descanso. Tómate un refresco, date un paseo. Si llega la idea, termina tu descanso, la idea no se va a ir. Si no surje la idea, plantéate si el objetivo que te has propuesto es correcto, realista y adecuado. Utiliza una botella de agua para descansar al cabo de unas horas; utiliza el sueño tras cumplir tus objetivos al cabo del día; utiliza los fines de semana para verificar el progreso y utiliza las vacaciones (tres o cuatro semanas es lo recomendable) para recargar las pilas para el resto del año.

Comienza de nuevo

¿Qué haces cuando te encuentras perdido? Tira todo el código y vuelve a empezar. A veces conviene que le cuentes lo que estás haciendo (y sobre todo, cómo) a un compañero; si él no lo ve claro, quizá sea buena idea comenzar de nuevo. Utiliza Pair Programming en estos casos también.

Escritorio barato, silla fantástica

Invierte en escritorios baratos, simples, feos y sobre todo espaciosos. Invierte también en las mejores sillas posibles, lo más cómodas posibles. Cuando se hace Pair Programming, cuida el que ambos programadores queden enfrente del monitor y que el teclado se pueda desplazar fácilmente.


Referencias:

“Test-Driven Development by Example
Kent Beck

Un pensamiento en “Test Driven Development: Patrones (I)

  1. Una muy interesante aproximación a TDD. Me encanta lo que va “más allá” del desarrollo: el descanso, la programación por parejas (en lo de la silla cómoda y el escritorio feo, jeje). Espero con atención las próximas entradas (yo también tengo pendientes algunas).

    Saludos.

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