El Blog de Ana Buigues » TDD http://anabuigues.com Wed, 07 Dec 2011 16:07:47 +0000 es-ES hourly 1 http://wordpress.org/?v=3.4 Cómo fue el Global Day of Coderetreat 2011 en Madrid http://anabuigues.com/2011/12/06/como-fue-el-global-day-of-coderetreat-2011-en-madrid/ http://anabuigues.com/2011/12/06/como-fue-el-global-day-of-coderetreat-2011-en-madrid/#comments Tue, 06 Dec 2011 20:42:01 +0000 Ana Buigues http://anabuigues.com/?p=3734

El pasado 3 de diciembre se llevó a cabo en todo el mundo el evento denominado Global Day of Coderetreat, el cual reunió a unos 2000 desarrolladores alrededor del mundo, todos participando el mismo día en una actividad denominada coderetreat.

¿Y qué es un coderetreat? según Corey Haines que es el impulsor de todo esto, es una práctica que se realiza durante todo un día, centrada en los fundamentos del diseño y desarrollo de software. Suelen resolverse problemas sencillos en un entorno en el que solo es importante aprender. El formato del coderetreat ha demostrado ser un medio altamente efectivo para mejorar nuestras habilidades.

Se realizan iteraciones de 45 minutos realizando pair programing y TDD. Después de cada iteración se realiza una retrospectiva para saber como ha ido, se cambia de pareja, se borra el código y se empieza con la resolución del problema desde cero. No importa si después de 45 minutos no hemos logrado escribir una sola línea de código o no hemos resuelto el problema completo, siempre y cuando esa línea o todo el código lo hayamos escrito de la mejor manera posible.

El Coderetreat de Madrid se celebró en Camon, tuvimos como facilitador a Enrique Comba que nos guió en el clásico problema del Juego de la Vida de Conway durante las diferentes iteraciones realizadas.

1ª Iteración

En esta primera iteración no había ninguna restricción, sirvió como toma de contacto con el problema. Lo que aprendí en esta iteración es a no empezar a construir la casa por el tejado!

2ª Iteración

Las restricciones en esta iteración eran que no podíamos usar tipos primitivos, todo tenía que estar en objetos y no podíamos usar ifs. En esta iteración no tuvimos ningún problema, siempre pensando en OO.

3ª Iteración

Varias restricciones… de primeras no podíamos tener métodos de más de 2 líneas. A mitad de la iteración se añadió la restricción de programar haciendo ping-pong en silencio. El hecho de no poder hablar con tu compañero hizo que se nos atragantase bastante la iteración. Lo que aprendí es que tenemos que escribir los test y la lógica de una manera suficientemente sencilla y clara para que otro programador sea capaz de entender que hemos hecho.

4ª Iteración

En esta iteración teníamos que escribir el peor código que se nos ocurriese, y a mitad de iteración teníamos que hacer lo contrario, intentar cambiar el código escrito para que quedase de la mejor forma posible. Al iniciar esta iteración pensaba que lo de escribir un código feo y malo iba a ser sencillo, pero tengo que decir que la verdad es que nos resulto bastante complicado después de 3 iteraciones escribiendo buen código. Aunque en la retrospectiva me di cuenta que todo era cuestión de imaginación! nombres que no tengan nada que ver lo que se está haciendo, escribir código innecesario simplemente para que no sea legible etc…

5ª Iteración

En esta iteración la restricción era TDD as if you meant it, hacer todo el código en el propio test y sólo sacarlo a método cuando se repita, y luego si hay métodos que tengan pinta de clase sacarlos. Es una práctica difícil y dura pero a la vez interesante ver como pasito a pasito se llega a una sencilla solución. Es la iteración que más me gusto.

6ª Iteración

Es esta iteración las restricciones eran clases inmutables, no podíamos utilizar fors y no podíamos utilizar algoritmos. Esta iteración nos fue bastante bien, creo que por ser la última.

Fue mi primer coderetreat  y tengo claro que voy a repetir, es un día en el que practicas y te diviertes a la vez, cosa que muchas veces no ocurre. Conoces a gente estupenda y te llevas muchos tips a mejorar.

Finalmente podéis ver el vídeo que grabó Enrique Comba, y así ver lo bien que nos lo pasamos!

]]>
http://anabuigues.com/2011/12/06/como-fue-el-global-day-of-coderetreat-2011-en-madrid/feed/ 10
Must Read: Diseño Ágil con TDD de Carlos Blé http://anabuigues.com/2011/11/13/must-read-diseno-agil-con-tdd-de-carlos-ble/ http://anabuigues.com/2011/11/13/must-read-diseno-agil-con-tdd-de-carlos-ble/#comments Sun, 13 Nov 2011 13:24:43 +0000 Ana Buigues http://anabuigues.com/?p=3624 Recientemente he leido Diseño Ágil con TDD de Carlos Blé y considero que su lectura es una magnifica forma de introducirse en el mundo de la practica del Test Driven Development.

Para los que desconozcan que es TDD es una técnica de desarrollo de software enmarcada dentro de la metodología eXtreme Programming que tiene la virtud de minimizar el número de defectos del código y maximizar su calidad creando un código limpio que funcione.

El libro se divide en dos partes, un teórica y una práctica. En la parte teórica realiza una pequeña introducción sobre la importancia del Agilismo. Pasa a explicarnos el algoritmo del TDD y realiza un recorrido por los distintos tipos de test como son los Test de Aceptación, Test Funcionales, Test de Sistema, Test Unitarios y Test de Integración. También nos explica cuando usar los dobles de prueba y como escribir código que cumpla con los principios de diseño S.O.L.I.D.

La lectura de esta primera parte resulta realmente enriquecedora, introduce muchos aspectos del “como se deben realizar las cosas”, se nota que la artesanía del software es un papel importante dentro de esta técnica de desarrollo, bueno y del desarrollo en general.

La segunda parte es puramente práctica, dónde se aplica todo lo aprendido en la parte teórica paso a paso. Se realiza un ejemplo partiendo de los test de aceptación, de esta forma nos centramos específicamente en el problema a resolver. Se van desarrollando los test utilizando TDD y se observa como el código va cambiando y adaptándose a los requisitos de una manera incremental.

Qué beneficios obtenemos:

  • Escribimos código de calidad.
  • Los diseños son más simples, nunca escribimos más código del necesario.
  • Aumenta la fiabilidad del código gracias a los test.
  • Conseguimos código muy reutilizable.
  • La tranquilidad de realizar modificaciones, si rompemos algo un test nos lo dirá.

Qué problemas encontraremos:

  • La técnica en sí es muy sencilla, pero llevarla a cabo cuesta, hay que cambiar nuestra forma de pensar las cosas.
  • Estamos acostumbrados a escribir código que funcione y punto, ni refactorizaciones ni principios…El dilema del “no tengo tiempo o no hay tiempo” ya no vale.

Los ejemplos del libro están escritos en C#, yo los realicé en Java, los podéis encontrar aquí.

]]>
http://anabuigues.com/2011/11/13/must-read-diseno-agil-con-tdd-de-carlos-ble/feed/ 8
Diviértete practicando TDD con Pulse y TDGotchi http://anabuigues.com/2011/09/20/diviertete-practicando-tdd-con-pulse-y-tdgotchi/ http://anabuigues.com/2011/09/20/diviertete-practicando-tdd-con-pulse-y-tdgotchi/#comments Tue, 20 Sep 2011 17:41:33 +0000 Ana Buigues http://anabuigues.com/?p=3597 El Test Driven Development  o desarrollo guiado por pruebas es una técnica de diseño de software que se basa en tres sencillos pasos:

  1. Rojo: escribimos la prueba primero cuando la funcionalidad está todavía por implementar, provocando el rojo.
  2. Verde: escribimos el código más sencillo que haga que la prueba funcione, provocando el verde.
  3. Refactorización: arreglar el código, extrayendo métodos, quitando duplicados, mejorando el nombre de métodos, clases, atributos…

Es importante que sigamos los pasos al pie de la letra, porque de lo contrario, no llegaremos a exprimir al máximo la técnica como herramienta de diseño.

Pulse y TDGotchi son dos plugins de Eclipse que nos ayudan a divertirnos mientras practicamos TDD.

Pulse

Pulse hace una analogía a lo que sería la representación de los latidos de nuestro corazón en los monitores de los hospitales, de forma que nos muestra nuestro pulso practicando TDD. Cuando obtenemos un rojo en nuestros test se mostrará un pico hacia abajo, cuando obtengamos un verde se mostrará un pico hacia arriba y cuando refactorizemos se mostrará un pequeño pico azul hacia arriba. Se muestra como una vista en Eclipse.

¿Y para qué nos sirve? pues para comprobar que realmente seguimos los pasos de TDD, a mi me ayudó para darme cuenta de que algunas veces me saltaba algún paso. Además podemos guardar nuestras sesiones de pulsos para posteriormente ver nuestro progreso, o compararlas con otros compañeros a modo de pique por ver quién lo hace mejor :P

TDGotchi

TDGotchi funciona como los famosos tamagotchi que se pusieron de moda hace tiempo (yo tuve uno). Es una mascota virtual que se alimenta de tus tests y tus refactorings. El sistema de puntuación para alimentar a nuestra mascota es el siguiente:

Como veis, obtener un doble rojo es penalizado de una forma bastante elevada así que cuidado con ellos porque cuando realizamos tres o cuatro de ellos la puntuación negativa es tan alta que casi imposible de remontar, lo bueno (o malo según se vea) es que cuando abrimos de nuevo nuestro Eclipse, la puntuación vuelve a estar a 0.

La mascota irá aumentado o disminuyendo de nivel, dependiendo de nuestra puntuación, nos podemos convertir en un zombi con una puntuación negativa o ir mejorando nuestro nivel cuanto mayor sea la puntuación obtenida.

Este plugin ayuda a seguir el sistema de tres pasos de TDD a raja tabla, ya que nadie quiere convertirse en un zombie!!!

Por último felicitar a su creador @Sebastian por el gran trabajo realizado y hacer que practicar TDD sea tan divertido.

]]>
http://anabuigues.com/2011/09/20/diviertete-practicando-tdd-con-pulse-y-tdgotchi/feed/ 12