Archivo de la etiqueta: tdd

Mis motivaciones con TDD y ATDD

Cuando pienso en (A)TDD me vienen a la cabeza dos cosas: simplicidad y reducción del desperdicio, dos cosas que son, en mi opinión, dos caras de la misma moneda.

El diseño de software, no importa como se lo mire, es un proceso complejo. El diseño, no importa de que cosa, es un proceso complejo. Nuestro cerebro no es capaz de evaluar todas las variables o grados de libertad en abstracto, como hacen los buenos jugadores de ajedrez tomando en cuenta muchas jugadas hacia adelante.

Es por esto que necesitamos concretar, eliminar grados de libertad, probar ideas.

¿Como reduce el desperdicio (A)TDD?

Evitando dedicar tiempo a construir (y probar, depurar, mantener, etc.) cosas que no necesitamos, utilizando el proceso:

    1. analizo las necesidades
    2. pienso como resolverlas
    3. decido como probar lo que construiré, con ejemplos concretos
    4. escribo una prueba que falle para el ejemplo mas simple
    5. escribo el código mas simple posible que hace pasar la prueba
    6. aprovecho oportunidades para mejorar mi código y pruebas

Veo este proceso como una suerte de embudo que me obliga a trabajar solo en lo que necesito, por ejemplo:

    • en el paso 5 escribo solo el código necesario para pasar el test
    • en el paso 4 escribo la prueba basada en el el ejemplo concreto mas simple sin resolver
    • en el paso 3 pienso en ejemplos concretos de lo que quiero lograr (no en “posibles” necesidades abstractas)
    • en el paso 2 dedico unos minutos a pensar como resolveré las funcionalidades (no comienzo a programar ciegamente)
    • en el paso 1 dedico un tiempo a entender el contexto de lo que debo hacer

Este proceso respeta dos cuestiones transversales muy importantes: se repite en ciclos cortos y la calidad no es opcional (calidad es arquitectura, rendimiento, cumplir con estándares, documentación, etc.)

 ¿La simplicidad?

Encuentro la simplicidad en los mismos puntos anteriores pues no construyo nada que no sea necesario por un paso en el proceso que mencioné antes, sumando al combo al refactoring, esa simplificación de mis artefactos que me permita no solo sostener y mejorar el ritmo de trabajo a lo largo del proyecto.

¡Nos vemos!

La magia de TDD

Nos encontrábamos ayer en las oficinas de Kleer, en un Yoseki Codig Dojo, exclusivo para un equipo de un cliente, trabajando con la Kata CheckOut.

Quiero contarles solo 3 minutos donde se notan las ventajas de diseñar nuestro código a partir del ejemplo.

Trabajamos en Java con Eclipse pues este es el entorno de desarrollo en el cual el equipo trabaja. Les presento el código al comienzo de los 3 minutos mágicos:

int cantA = 0, cantB = 0, cantC = 0, cantD = 0;
for(String producto: productos.split(","))
{
    if (producto.equals("A"))
        cantA++;
    else if (producto.equals("B"))
        cantB++;
    else if (producto.equals("C"))
        cantC++;
    else if (producto.equals("D"))
        cantD++;
}
return cantA*50 + cantB*30 + cantC*20 + cantD*15;

Decidimos, en ese momento, eliminar la duplicación de lógica (en la declaración de variables y en la cadena de ifs). Entonces, quien estaba al teclado dijo: “Podemos hacer una método para encapsular la lógica…” a lo cual yo respondí: “¡Adelante!”. Entonces esta persona escribió:

private ...

y sobrevino una larga pausa, luego un debate.

El problema es que hay mucho que decidir si vamos por ese camino: ¿Cuál es el tipo que retorna ese método? ¿Cuál debería ser su nombre? ¿Qué parámetros debe recibir? y, sobre todo, ¿Qué debe hacer?.

Luego de dar tiempo al debate, sugerí eliminar esa línea de código y escribir lo siguiente:

return getCantA(productos)*50 + cantB*30 + cantC*20 + cantC*15;

Noten que reemplace la variable cantA por el llamado al método getCantA(…), aun inexistente.

En ese momento quedaron muy claras las respuestas a las preguntas: el método debe devolver un entero, su nombre ya esta definido y debe sumar la cantidad de productos de tipo A. En 15 segundos quedo escrito lo siguiente:

private int getCantA(String productos)
{
    int cant = 0;
    for(String producto: productos.split(","))
    {
        if (producto.equals("A"))
            cant++;
    }
    return cant;
}

Y las pruebas unitarias pasaron y el pequeño paso en el refactoring fue exitoso.

A esto me refiero con la magia de TDD. Es muy difícil diseñar el método “desde adentro”. Es mucho mas fácil y efectivo diseñarlo “desde afuera”, es decir, desde el lugar donde lo necesitamos.

Para aquellos que estén preocupados por el final de la historia (o de este refactoring), les cuento que el último paso dejó el código en estas condiciones:

private int price(String productos)
{
    return getCant(productos, "A")*50 + 
           getCant(productos, "B")*30 + 
           getCant(productos, "C")*20 + 
           getCant(productos, "D")*15;
}
private int getCant(String productos, String codProducto)
{
    int cant=0;
    for(String letra : productos.split(","))
    {
        if(letra.equals(codProducto))
            cant++;
    }
    return cant;
}

Luego siguieron otros refactorings, por supuesto, pero eso fue luego de los 3 minutos mágicos, así que termino esta entrada aquí.

Si alguno de ustedes quiere experimentar algo parecido, no dejen de organizar coding dojos en sus lugares de trabajo, un lunes por la mañana, un viernes por la tarde, cuando sea.

Si no se sienten seguros para comenzar, participen de un Yoseki Codig Dojo en Kleer, los organizamos mensualmente en Buenos Aires, en Lima, y en otras ciudades. Y son gratuitos.

TDD y Arquitectura en Rosario

Luego de tres años, el último viernes y sábado estuve en Rosario compartiendo buenos momentos con colegas de esa ciudad.

Lo mejor (y el verdadero motivo del viaje) fue la cena y el almuerzo (pizza y asado respectivamente).

El viernes los aburrí un poco con una sesión sobre TDD. Si alguien esta interesado puede acceder a la grabación aquí.

También pueden descargar el archivo WMV desde este link (click secundario y guardar destino – el tamaño aproximado es 80MB).

El sábado (mientras haciamos tiempo antes de ir a la parrilla), hablamos de MonoRail.

Muchas gracias a mis colegas rosarinos. Nos veremos pronto.