Archivos de la categoría tdd

Coderetreat en Buenos Aires

gdcr-1

UPDATE: Sumamos a Cinchcast como sponsor (una startup estadounidense con un equipo de 10 desarrolladores en Buenos Aires). Ya esta solucionado el almuerzo, creo que habrá sorpresas. También agradecemos a Kleer, por sus oficinas.

Este año, junto con Benjamin Eidelman (aceptamos ayuda) y Ágiles Argentina, estamos organizando, el Global Day of Coderetreat en Buenos Aires.

La experiencia anterior, en el año 2011, fué muy interesante, compartimos el día con desarrolladores de todo el mundo, desde Honolulu hasta España y Japón (150 ciudades en todo el mundo). Incluso, establecimos comunicación vía Skype con algunos de los grupos.

¿Qué ocurre en un coderetreat?

Nos reunimos desarrolladores interesados en mejorar nuestras habilidades. Practicamos la resolución de varios problemas de programación, con distintos lenguajes, distintos colegas, distintos objetivos.

¿Cómo puedo participar?

Si deseas inscribirte (¡solo 18 lugares!), por favor hazlo en el Meetup del evento. También puedes visitar la página del evento en el sitio de la comunidad mundial de Coderetreat.

Si tienes ideas o propuestas, por favor usa los comentarios de Meetup, queremos mantener centralizada y visible para todos esa información.

¡Nos vemos!

TDD no es prueba, es diseño.

En una de las últimas sesiones de coaching en la cual ayudé a un equipo a experimentar TDD, escuché una de las reacciones mas usuales ante el primer paso.

Para definir el contexto, imaginen que van a escribir la famosa kata tenis y que aun no han escrito absolutamente nada de código. Una de las posibilidades es escribir esta prueba:

[Test]
public void ShouldProvideTheScorerTitle() {
var scorer = new Scorer("Federer", "Nadal");
Assert.AreEqual("Federer vs. Nadal", scorer.Title());
}

Y una de las posibilidades para el código mas simple posible que hace pasar ese test, es:

public class Scorer {
public Scorer(string jugador1, string jugador2) {
}

public string Title() {
return "Federer vs. Nadal";
}
}

La reacciones suelen ser: ¿Por qué debemos escribir ese código tan tonto ahora? ¿Por qué no creamos directamente las variables de instancia para los nombres de los dos jugadores? ¿Qué sentido tiene devolver ese texto fijo? ¡Esa prueba no tiene sentido!

Mi respuesta usual es: No tiene sentido porque no es una prueba, es una actividad, un paso, una canal por donde fluye el diseño.

¿Qué tenemos antes de empezar? Nada concreto, solo una idea de lo que tenemos que hacer y alguna estrategia de diseño que debemos aún desarrollar, entender.

Luego del primer paso tenemos: el nombre de la clase, decidimos que pasaremos los nombres de los jugadores en el constructor, que basta con pasar los nombres como string, que usaremos un método para devolver en título y que ese método retornará un string.

Lo mas importante es que tenemos todas estas decisiones antes de escribir el código de producción, solo habiendo escrito la prueba.

¿No les parece que hemos diseñado mucho en un solo paso como para preocuparnos por detalles de implementación?

Por ejemplo, ¿es razonable que un músico se obligue a escribir música de manera que cada paso tenga sentido en la versión final? Por supuesto que no, empieza a jugar con notas y melodías (a partir de alguna idea) y luego va desarrollando, en forma iterativa la versión final.

A medida que va avanzando entiende mejor como se ajustan todos los bloques, la idea va tomando forma, va entendiendo que es lo que quiere la pieza musical.

Hay otros motivos importantes por los cuales debemos escribir el código mas sencillo posible, pero hay mucho material sobre esos motivos en la red y, en todo caso, puede ser materia de una futura entrada.

Creo un requisito importante para lograr una buena práctica de TDD es entender e incorporar la idea de que no es una técnica de prueba sino una manera de diseñar software.

Nos vemos.