La dinámica que voy a describir aquí fue diseñada por Gabi Falcone para una clase de Algo3@Fiuba. El objetivo de la misma es presentar las pruebas automatizadas y su uso como herramienta de especificación.

Contexto: en el curso tenemos alrededor de 50 alumnos. El aula de clase no tiene computadoras, pero algunos alumnos traen sus portátiles.

Preparación

Previo a la clase se le pide a alumnos resolver un problema de programación que implica crear algunas clases. En necesario contar con al menos dos problemas de complejidad similar. Dependiendo de la cantidad de alumnos puede resultar conveniente contar con más problemas. En nuestro caso trabajamos con 3. Se le pide a cada alumno resolver solo uno de los problemas. Para esto nosotros solemos utilizar una heurística basada en el número de padrón:

• padrones terminados en 0,1,2,3 => problema 1
• padrones terminados en  4,5,6 => problema 2
• padrones terminados en  7,8,9 => problema 3

La clase comienza con una explicación conceptual de pruebas unitarias automatizadas y del framework xUnit. En nuestro caso explicamos SUnit pues trabajamos con Smalltalk. Luego de la explicación se pone manos a la obra con la dinámica de trabajo interactiva.

La dinámica se hace en grupos donde cada grupo tiene una computadora. El primer paso entonces es armar los grupos. Se le pide a todos que salgan del aula, armamos tres filas con la gente que había resuelto cada variante del problema pedido inicialmente. A continuación en cada fila se le pide a los que tengan computadora que pasen al frente y elijan 2 o 3 compañeros de la fila que no tengan computadora. Así quedan armados los grupos. A continuación se les pide volver a entrar al aula y que se ubiquen en las mesas según los grupos armados.

Primera etapa

Segunda etapa

Cada grupo entrega el conjunto de pruebas creadas (sólo el código de las pruebas, no el código que hace pasar las pruebas) a otro grupo que haya estado trabajando sobre un problema distinto. Ahora cada grupo debe resolver un problema nuevo pero en este caso tiene un conjunto de pruebas como especificación de lo que debe resolver y al mismo tiempo puede ir corriendo esas pruebas para verificar la solución que va generando. Una vez más se pide explícitamente que vayan rotando el conductor.
Al cabo de unos 30 minutos, deben tener la mayoría de las pruebas pasando.

Cierre

Aquí se pide a los alumnos dejar a un lado las computadoras para hacer una puesta en común de la actividad. Se plantean algunas preguntas para disparar la discusión:

• ¿Cómo les resultó la experiencia en general?
• ¿Cómo les resultó el resolver un problema a partir de una especificación en forma de pruebas?
• ¿Cómo les resultó escribir pruebas para un problema ya resuelto? ¿Qué utilidad le ven a esto?

Nota: tener presente que durante esta actividad no se hace TDD sino que simplemente se utilizan pruebas como especificación lo cual es solo una parte de TDD. Notar que aquí el trabajo comienza con todo un conjunto de pruebas ya escrito, mientras que en TDD las pruebas se van escribiendo de a una por vez.