#iwt2

Adelantamos el dojo del 30 al jueves 29 de mayo en el aula A4.30.

El primo lunes 19 de mayo tendremos las 10ª convocatoria del #IWT2 DojoUS. Inscríbete en este formulario de Google.

 Después de más de dos años practicando TDD en nuestro dojo, que también es el tuyo, es la hora de buscar nuevas fronteras, por lo que dedicaremos este dojo a ver y empezara a practicar con Behaviour Driven Develoment o BDD.

  ¿Qué es BDD?

TDD sirve para escribir código. BDD, en cambio viene en nuestra ayuda cuando queremos aplicar las mismas ideas de TDD pero empezando por los requisitos y escenarios de uso y trabajando con usuarios finales.

Existen varios aspectos que se pueden abordar a la hora de aplicar BDD, como técnicas para escribir buenas historias de usuario, para tener una comunicación eficaz con los clientes y usuarios, modelos y patrones de arquitectura y diseño que encajan con esta filosofía, lenguaje ubicuo, etc.

En este primer dojo de BDD nos centraremos en empezar a aplicar algunas de las herramientas más habituales

  ¿Qué herramientas utiliza BDD?

Las herramientas más conocidas de BDD son aquellas que permite implementar escenarios como pruebas. Algunas de las más conocidas son RSpec, Cucumber, Lettucew, Behave, Jasmine, etc. Aunque estas herramientas no dependen tanto del lenguaje de programación, actualmente casi todos los lenguajes cuentan con alguna herramienta nativa.

Imagen tomada de http://blog.bughuntress.com/automated-testing/automated-testing-with-behavior-driven-testing

En el dojo utilizaremos Cucumber, la versión de Java desde el IDE Eclipse y, para los que quieran ver algún ejemplo en Python, Behave.

  Agenda del dojo

Comenzaremos a las 19 con una brevísima introducción a qué es Behaviour Driven Development para aclarar dudas que se puedan tener.

Después, sobre las 19:30 haremos un ejemplo guiado (o demo), o demo, en el que cogeremos una kata, la explicaremos, definiremos un escenario, lo implementaremos como prueba y escribiremos el mínimo código posible para que la prueba se ejecute con éxito.

A continuación, sobre las 20:00 – 20:15, nos pondremos todos en pareja y, cada pareja continuará escribiendo nuevos escenarios para completar funcionalidad o añadir funcionalidad nueva. Finalmente, sobre las 20:45 haremos una retrospectiva del trabajo hecho.

  ¿Qué hay que traer?

Sobre todo ganas de programar. Un dojo NO es una charla técnica en la que cruzas los brazos y dejas que te lo den todo hecho. Un dojo es un sitio en el que trabajar y practicar para mejorar. Si buscas una charla de BDD, esta no es la mejor opción, pero si quieres traer tu portátil (o utilizar alguno de los ordenadores de allí) y empezar a practicar este es el sitio perfecto.

Aquí tenéis toda la información. Nos vemos el miércoles 23. Un saludo.

Fecha y hora

Miércoles 23 de abril de 19:30 a 21:00 en las instalaciones de CoLaborando. Calle la Plata, 21 41500 Alcalá de Guadaíra (Sevilla - España). 955 68 08 17. http://www.coworkingcolaborando.com/es

Objetivo

Aprender desarrollo dirigido por pruebas (Test-Driven Development o TDD) mientras haces TDD y te lo pasas bien.

Descripción

En este dojo de código realizaremos una kata aplicando TDD y, después, una puesta en común de los resultados y pequeño coloquio sobre TDD, como comenzar, como mantenerlo, los errores más habituales, etc.

Agenda y organización

19:30 - 19:50 Presentación del dojo y del ejercicio

19:50 - 20:20 TDD timeboxed

20:20 - 20:40 TDD libre

20:40 - 21:30 Puesta en común, networking y charlas

Comenzaremos a las 19:30 con una brevísima introducción a TDD y organizando el trabajo. Así, además, daremos tiempo para que se unan los compañeros que no puedan llegar antes.

Después explicaremos el enunciado de la kata y comenzaremos a aplicar TDD timeboxing. Con esta variante plantearemos cuál es el siguiente paso que queremos lograr, propondremos un tiempo para lograrlo (de pocos minutos en el mejor de los casos) y después comentaremos brevemente posibles soluciones. Así aprenderás rápidamente la mecánica y filosofía de TDD.

Una vez que ya te hayas acostumbrado a seguir los ciclos de TDD será el momento de que continúes por tu cuenta y a tu propio ritmo. Después, haremos una puesta en común de la solución y terminaremos hablando entre todos sobre los problemas y las ventajas de utilizar TDd y lo que surja.

¿Qué es TDD?

Una de las técnicas ágiles que más difusión ha alcanzado es el desarrollo dirigido por pruebas o TDD en sus siglas en inglés. Esta técnica propone el diseño del código de manera interactiva, planteando el desarrollo desde la perspectiva de cuál es la manera más adecuada de utilizar el código en lugar de qué elementos debe tener, y creando un conjunto de pruebas que nos avisen inmediatamente hemos introducido algún cambio que modifique su funcionamiento.

Más sobre una kata

Las katas de programación y TDD, al igual en el las artes marciales, son una serie de ejercicios pensados para practicar las habilidades de programación y convertirte en un mejor programador.

El objetivo de una kata no es terminarla rápidamente o de cualquier manera, sino el tener la oportunidad de aplicar nueva sideas o variantes y descubrir maneras más elegantes y efectivas que te ayuden a resolver el trabajo del día a día.  

¡Las katas son ejercicio de programación organizados por personas para personas! Si tienes alguna duda sobre las katas, o TDd o tu entorno de desarrollo o si puede ser ser una buena idea asistir o no escribe al facilitador a esta dirección de correo: [email protected] y coméntaselo, que su misión es ayudar en todo lo que le pidan.

Perfil de los asistentes

Cualquier persona con interés en la programación y ganas de aprender, mejorar y conocer a otros compañeros de profesión y de pasión es bienvenida.

Para sacar el máximo partido a tu visita al dojo es conveniente que traigas tu portátil con el entorno de desarrollo que quieras utilizar. Un dojo puede ser la oportunidad perfecta de probar por fin ese IDE que tanto te llama la atención o ese lenguaje nuevo con el que querías empezar.

Para ser capaz de resolver la kata es necesario tener conocimientos de programación y ser capaz de escribir pruebas automáticas. Si puedes escribir una prueba que verifique la suma de dos números entonces tienes el nivel perfecto para una kata.

Recuerda que el dojo no es un lugar dónde aprender programación sino un lugar dónde aprender a ser un mejor programador. Si no tienes el nivel también estás invitado a venir a ver los ejercicios o a hacer pareja con otro participante. Seguro que puedes ayudarle.

En la entrada anterior,  Crónica del #IWT2 DojoUS y la kobuto kata REST-Consumer,  vimos la 9ª reunión del #IWT2 DojoUS, un dojo de código que celebramos en la ETSII desde 2.012. Nos quedó pendiente darle un repaso al código que hicimos en el dojo, así que vamos allá. En esa reunión, nos planteamos resolver la kobudo-kata del índice G, que calcula lo guay que es un repositorio de GitHub.

Empezando por el final

Tienes una versión de esta kobudo-kata junto con su enunciado en el repositorio de Kobudo-Katas en GitHub. Anímate a hacerla y a practicar TDD, código para humanos, etc. mientras te conectas a un API REst.

El objetivo de una kobudo kata es aprender, practicar pero también utilizar herramientas que también se emplean en el día a día de la programación, por lo que nos tiramos de cabeza a consumir la auténtica API Rest de Github y trabajar con repositorios reales.

  Moviendo datos de acá para allá.

Para calcular el índice G necesitamos las estrellas, watchers y forsk de un repositorio. Como tenemos que mover esta información desde el código que lee repositorios hasta el código que calcula el índice G, la encapsulamos en un sencillo Data Transfer Object que, además, es inmutable.

Este DTO y el servicio que calcula el índice G lo tenéis a continuación (en Python, que fue el lenguaje que utilizamos para la kobudo kata).

Veamos ahora que hicimos para acceder a los repositorios de Github

Al asalto de Github

El código que lee la información e un repositorio de Github y devuelve el DTO se muestra a continuación.

Esta es la parte principal de la kata y la que puede dar más dificultades. Si observas el método get_repos_from de la línea 32 verás que accede directamente a Github. ¿Cómo se puede probar esto? Nosotros utilizamos HTTPretty que intercepta la llamada. Si no tienes, o no quieres usar ninguna herramienta puedes darle un cambio al diseño. Tienes más detalles sobre esto en la entrada anterior.

 Sin embargo, aunque funciona bien y se puede probar, el código de la clase RepositoryService  (línea 30) no es todo lo bueno que podría ser. Estos son algunos malos olores que yo veo, pero puedes comentar más malos olores o cosas que no te gusten más abajo en los comentarios.

No hay nada que indique que debes llamar a método get_repo y que él ya se encarga de llamar a los otros métodos.

No cumple el principio de single reponsibility.

Tiene una cohesión muy baja ya que los métodos son independientes, incluso podrían ser estáticos.

No hagas llorar al tío Bob

 Detengámonos en el principio de responsabilidad única. Este principio, la S de los principios SOLID, nos dice que toda clase debe tener una única responsabilidad, o, en otras palabras que debe tener un único motivo para el cambio. Repasa el código de la clase RepositoryService  (línea 30). ¿cuántos motivos para cambiar ves?.

Por ejemplo, imagina que queremos leer repositorios de otra fuente. Tenemos que cambiar la clase RepositoryService. Ahora supón que lo que queremos es cambiar el constructor  de la clase Repo porque también queremos guardar el JSon original o porque preferimos utilizar métodos set. También tendríamos que modificar la clase RepositoryService. Sin embargo estos dos cambios no tienen nada que ver entre sí. Hemos descubierto dos responsabilidades diferentes.

Otro ejemplo, supón que algunos repositorios no tiene estrellas. El código que accede a Github  será el mismo, pero el método get_repo fallará. Este es otro ejemplo de más de una responsabilidad.

Una de estas responsabilidades es candidata a ir a su propia clase. Tal y como puedes ver en la solución de Github, hemos sacado la responsabilidad de procesar el JSon y construir el DTO a una factoría (línea 48). 

Conclusión

Una de las principales ventajas de TDD es que nos empuja a utilizar buenas prácticas de diseño y programación y estás prácticas nos permiten hacer cosas tan interesantes como retrasar las decisiones técnicas y de arquitectura.

Imagina lo siguiente, ¿qué hubiera pasado si, desde el primer momento, hubiésemos querido hacer una aplicación web? ¿Hubiésemos dejado de lado la parte web hasta que ya tuviéramos el código funcionando o, por el contrario, hubiéramos cogido un framework web y hubiéramos empezado a tirar millas?

En la próxima entrada veremos cómo utilizar Django que crear una interfaz web al código que ya tenemos escrito, sin tocar una coma.

El viernes 21 de marzo tuvimos la 9ª reunión del #IWT2 DojoUS, un dojo de código cobijado por el grupo de investigación en Ingeniería Web y Testing Temprano de la Universidad de Sevilla, dónde todos sois bienvenidos.

En esta ocasión planteamos resolver la kobudo kata Rest-Consumer para calcular lo guay que es un repositorio de Github en base a una serie de parámetros. Utilizaremos el API Github para trabajar con repositorios reales. Podéis encontrar el enunciado completo y algunas soluciones en Solveet . La solución propuesta también puedes encontrar en mi Github .

A continuación tenéis la crónica de todo lo que pasó.

¿Qué es una kobudo-kata?

  Entre otros significados, la palabra kobudo hace referencia a las armas clásicas de las artes marciales, las cuales a su vez son variantes de las herramientas de los campesinos, pescadores, etc. Una kobudo kata no solo nos retan a implementar código aplicando buenas prácticas o clean code, sino que además,  utilizamos las mismas herramientas que aplicamos en el día a día: bases de datos, interfaces web, etc.

Una tarde en el dojo

La asistencia fue espectacular, de las 14 personas inscritas aparecieron 10, aunque al final solo quedamos 6 valientes. Además tuvimos a tres amigos que siguieron la kata por videoconferencia y que aportaron muchísimo. ¡Gracias a todos!

Muchos de los asistentes, por no decir todos, habían programado muy poco en Python. ¡Incluso para algunos era la primera vez que programaban en este lenguaje!. Al final del dojo no solo habían escrito sus primeras líneas sino que ya empezaron a trabajar con buenas prácticas como pruebas unitarias, inversión de dependencias, decoradores para crear propiedades, etc.

Puntos clave de la kata

Esta kobudo kata no es un ejercicio difícil. Incluso puede realizarse con sólo 2 líneas de código, sin contar imports. Pero el objetivo de un dojo y una kata no es terminar el ejercicio como sea sino aprender a escribir el mejor código posible.

Empezamos aplicando TDD y escribiendo código que no tenía ninguna dependencia externa, y pasamos a ver cómo acceder a una API Rest sin abandonar TDD en ningún momento. Utilizamos MagickMock (viene de serie en Python 3.x) y HTTPretty para escribir el código real que se accede a Github pero interceptar la llamada y hacer que devuelva el resultado que queramos. También vimos un ejemplo muy sencillo de patrón Model-View-Presenter para desacoplar nuestro código de la salida pro consola y poder probarlo con dobles de prueba.

 Probamos a ejecutar el código sin interceptar dicha llamada y el tiempo de ejecución aumentaba considerablemente, por lo que es una buena idea utilizar HTTPretty para poder ejecutar las pruebas muy  a menudo.

 Durante todo el tiempo estuvimos hablando de cómo hacer TDD, de cómo podríamos resolver los problemas que nos encontrábamos, etc. Alguno de los asistentes se sorprendió de mi insistencia por ejecutar las pruebas y ver que fallaban. Para mí esto es algo muy importante en TDD que te puede ahorrar varios quebraderos de cabeza.

  Y esto fue todo. Me queda pendiente recuperar el código que hicimos y darle un repaso crítico pero eso será en la próxima entrada. Ya estoy preparando el siguiente dojo así que permanece en sintonía y no te lo pierdas.

Nos leemos.

No te vayas aún

  En este mismo blog tienes más artículos sobre katas y dobles de prueba. Aquí tienes algunos.

Crónica del último DojoUS de 2013 sobre dobles de prueba

Con un poco de retraso por las fiestas navideñas toca hacer una crónica del último dojo del año, dedicado a los dobles de prueba. Finalmente tuvimos 6 asistentes, todos trabajando en el mismo proyecto lo que hizo que el nivel fuera muy homogéneo.

  Empezamos hablando de los distintos dobles de prueba: mocks, stubs, fakes, dummies, etc., y poniendo ejemplos de ellos. Después, cogimos Mockito (para Java) y vimos algunos ejemplos prácticos de cómo crear spies, semi-spies (a partir de una clase ya implementada), las diferencias con mocks, etc.

  La mayoría de los ejemplos eran similares a los ejemplos que podéis encontrar en la documentación de Mockito y en el anexo del libro Desarrollo dirigido por Pruebas Práctico 

  Después, estuvimos haciendo entre todos el ejemplo de un servicio que es invocado en una fecha determinada (días pares, meses múltiplo de 5, etc.), que podéis consultar en esta otra entrada implementado en Python y en esta entrada implementado en Java.

  Además, el código tanto de los ejemplos de Mockito como del ejemplo del servicio está subido a GitHub, podéis consultarlos en este enlace.

Conclusiones

  La experiencia fue muy muy buena y, por mí sensaciones y lo que me comentaron en el resto de asistentes, todos nos lo pasamos en grande. Eso, a pesar de no hacer el ejercicio que tenía preparado para practicar con dobles de prueba.

Ese ejercicio lo propuse también, hace algunas semanas, en Solveet y aquí tenéis el enlace por si alguien se anima a intentarlo. Prometo revisar todas las soluciones que se propongan.

También eché en falta no tener más ejemplos preparados con otras herramientas. Intenté montar un ejemplo con PowerMock pero no me funcionó. Justo después del dojo me di cuenta que tenía mal una anotación y, con ese cambio, ya funcionó perfectamente, así que subí este ejemplo con el resto de los materiales a GitHub para quien quiera consultarlo y además lo tenéis en esta entrada.

  Bola Extra

Los dojo IWT2 DojoUS vienen celebrándose desde octubre de 2.012 en la Escuela Técnica superior de Ingeniería Informática, gracias al apoyo, como su nombre indica, del grupo de investigación en Ingeniería Web y Testing Temprano . Tenéis las crónicas de los dojos anteriores en la sección #IWT2 dojoUS

  Quien quiera estar pendiente del próximo sólo tiene que ojear la web del IWT2 de vez en cuando o seguirme por twitter (o preguntarme directamente)