Show & Tell
occasionally subtle
Kaledo Art
he wasn't even looking at me and he found me
NASA
No title available
ojovivo
sheepfilms
Alisa U Zemlji Chuda
ellievsbear
Stranger Things
❣ Chile in a Photography ❣
blake kathryn
TVSTRANGERTHINGS
todays bird
Monterey Bay Aquarium
trying on a metaphor
Cosmic Funnies
@theartofmadeline
No title available
seen from Netherlands
seen from Malaysia
seen from T1
seen from Canada
seen from T1
seen from United States
seen from United States
seen from Chile
seen from Germany
seen from Malaysia
seen from Chile
seen from Türkiye
seen from United Kingdom
seen from Japan
seen from United States
seen from United Kingdom
seen from Singapore
seen from South Korea
seen from Malaysia
seen from Türkiye
@iwt2-javierj
Nuevo blog sobre LEGO, Agile y LEGO Serious Play
Llevo un año trabajando en talleres y simulaciones de técnicas ágiles usando LEGO y LEGO Serious Play y he creado un nuevo blog para contar mis experiencias.
La dirección es: https://agilego.tumblr.com/
Nos vemos allí.
TDD en Python (PyConES 2013)
Y preparando algo para el 2014 ;)
Contribute to curso_python development by creating an account on GitHub.
Poniendo en mi Github algunos pequeños scripts en Python para que sirvan de ejemplos y ejercicios en un curso de Python en el que participaré en Julio.
Son de código libre, así que quien quiera puede usarlo para lo que quiera
Pruebas que te entierran vivo. Un caso práctico
Las pruebas y el diseño desacoplado que obtenemos con TDD, facilita la refactorización y cambiar con la seguridad de que las pruebas nos avisarán si nos equivocamos.
Sin embargo, mal aplicadas, las pruebas se convierten en palos en las ruedas que impiden el cambio. Un ejemplo de este tipo de pruebas le he encontrado en el proyecto PyTDDMon. A continuación relato mi experiencia.
Entendiendo PyTDDMon
Esta herramienta se encarga de monitorizar un sistema de ficheros y ejecutar automáticamente todas las pruebas que encuentre en dicho sistema cada vez que detecta un cambio en un fichero. Los resultados los muestra en una pequeña ventana como la que se muestra a continuación.
PyTDDMon está compuesto por un único módulo, 7 clases (3 de ellas dedicadas a la interfaz gráfica), 13 funciones de módulo y 33 pruebas unitarias. La cobertura de las pruebas es del 34% (calculada con nosetest y coverage 3.7).
La complejidad ciclomática (o CC)es baja. La mayoría de funciones y métodos tienen una CC de 1 con algunas excepciones como las que se muestran a continuación.
Fallo de compatibilidad en Python y metedura de pata
Cuando se ejecuta PyTDDMon con la opción ---gen-kata=Nombre, generar un archivo con dos casos de prueba, siempre los mismos. El código de estos casos de prueba está guardado en una gran variable de texto.
Sin embargo, la prueba test_another_thing pasa o falla dependiendo de si se ejecuta en Python 2.x o 3.x ya que la función range cambió a partir de la versión 3.x
En las versiones 2.x de Python, range devuelve una lista con los elementos indicados incluyendo el primero pero sin incluir el último. Pero en las versiones 3.x, range devuelve una función generadora que, para cada llamada, devuelve el siguiente elemento, de manera parecida a un iterador en Java.
Esto hace que la prueba test_another_thing falle, ya que se está comparando un tipo lista con un tipo función.
Una manera sencilla de arreglarlo (no la única) es utilizar un list comprehension como se muestra a continuación. Con este cambio, las pruebas funcionan tanto en Python 2.x como en 3.x
Inocente de mí, hice un pull request para añadir este cambio a PyTDDMon. El resultado ya os lo imaginas: rechazado porque las pruebas fallaban.
De rojo a verde
El código de las pruebas que genera PyTDDMon está guardado en un atributo de la clase Kata.
Repasando las pruebas veo que hay un módulo test_genkata con pruebas para verificar la clase Kata. Esta clase es la encargada de generar el nombre y el contenido del fichero con las pruebas que hemos visto en la sección anterior. Algunas de estas pruebas se muestran a continuación.
Estas pruebas solo verifican el contenido de la cadena de texto que contiene el código que vuelva en el fichero que genera. Normal que algunas pruebas fallaran al cambiar la cadena de texto.
La solución más rápida es repetir en test_contains_an_list_equality_assertion el cambio anterior y, ahora sí, todo funciona correctamente.
Enterrado vivo en mis pruebas
El código de test_genkata es un MAL ejemplo de cómo NO hacer pruebas. Estas pruebas no verifican funcionalidad ni el resultado del código. En cambio, estamos comprobando que un atributo tiene un valor, y como hemos visto, ese valor es incorrecto.
Estamos duplicado código (el horror, el horror), ya que todo lo que pongamos, quitemos, o cambiemos en el código que genera también tendremos que hacerlo en las pruebas.
Estas pruebas no son un seguro para cambiar cosas con tranquilidad. En cambio, son un sarcófago de cemento que construimos alrededor del código y que hacen que hasta un cambio en una coma o en un espacio en blanco haga las pruebas fallar.
Estas pruebas no aportan nada.
Testopia, mejora tus pruebas
¿Cómo podríamos escribir buenas pruebas para este caso? El objetivo del código es crear un fichero de texto con dos pruebas válidas. Una primera idea sería comprobar si el fichero se crea y su contenido es el correcto, pero eso nos lleva a las mismas pruebas que hemos visto antes, con código duplicado que dificulta el avance.
Démosle una segunda vuelta. El objetivo del fichero generado es que contenga dos pruebas que pasan con éxito. Esta puede ser nuestras pruebas.
Vamos a ejecutar el código, a cercar un fichero a ejecutar el contenido y a verificar que el resultado es que dos pruebas se ejecuten correctamente. Además, podemos escribir dos juegos de prueba, uno de ellos para que ejecute el código en un entorno Python 2.x y otro para que lo ejecute en un entorno Python 3.x. Un ejemplo de una prueba así se muestra a continuación.
Si las pruebas no se ejecutan con éxito, el valor devuelto por el segundo call será distinto de 0.
Por último, refactorizamos estas pruebas para ilustrar el objetivo de la prueba ocultando los detalles técnicos. Un posible resultado se muestra a continuación.
Si hubiéramos contado con estas pruebas desde el principio, enseguida habíamos descubierto el fallo al usar range
Conclusiones
Las nuevas pruebas que hemos escrito no son perfectas. Son frágiles porque dependen de la configuración del sistema y si esta configuración cambia, o las llevas a otro ordenador, pueden fallar.
Sin embargo son las únicas pruebas que a mí se me ocurren y que aportan valor. Recuerda que el código que estamos probando se limita a crear un fichero y volcar dentro un texto predefinido.
Estas pruebas sí nos facilitan el cambio. Si queremos añadir nuevas pruebas, o nuevos entornos, por ejemplo una nueva versión e Python, nuevas librerías de prueba, etc., no es necesario modificar las pruebas ni reproducir en el código de prueba los cambios que hagamos en nuestro código de producción.
Bolaextra
Uno de los mejores pythonistas españoles (@Pybonacci en twitter y coordinando un estupendo blog http://pybonacci.wordpress.com/), también director del blog del mismo nombre) nos comenta que, otra alternativa para cambiar la prueba y que funcione en ambas ramas de Python es utilizar list de la siguiente manera: list(range[1, 3]). Además esta alternativa puede ser hasta el doble de rápida que utilizar una list comprehension
Un ejemplo sencillo de BDD con Cucumber y Java
El próximo jueves 29 de mayo celebraremos la 10ª edición del IWT2 DojoUS (en Sevilla, España). En esta ocasión, practicaremos y aprenderemos herramientas para aplicar Behaviour-Driven Development. Aún puedes apuntarte en el enlace anterior
En este mismo blog ya hemos hablado alguna vez de Python, BDD y la herramienta Behave, por lo que puedes encontrar un ejemplo en la entrada Un ejemplo de ATDD / BDD con Python y Behave
A continuación vamos a poner en marcha un ejemplo sencillo con Cucumber para Java. Así podrás comprobar que todo funciona perfectamente antes de venir al dojo.
Descargando las librerías.
Las librerías que he utilizado para el proyecto las puedes ver en esta captura.
Puedes bajar todo lo necesario de aquí, o bien añadir la dependencia al proyecto si usas Maven. Además necesitarás incluir la librería de JUnit 4 que ya viene incluida en Eclipse.
Escenarios
Cucumber permite implementar y ejecutar escenarios escritos en Gherkin como casos de prueba. Vamos a coger los escenarios del proyecto de ejemplo Calculator. En el siguiente enlace de Github tienes todos los ficheros.
Navega hasta aquí para localizar el fichero basic_arithmetic.feature con los escenarios de la calculadora.
Por defecto, Cucumber busca los escenarios en el classpath por lo que para que los puedan encontrar inclúyelos en una carpeta de código. Dentro de esa carpeta crea la misma estructura de paquetes donde estará el código.
Runner
Como Eclipse no trae soporte de serie para Cucumber, necesitamos escribir una clase Runner que lance la ejecución de los escenarios. Para crear tu runner muévete aquí y copia el fichero RunCukesTest.java.
Puedes comprobar si tu runner funciona ejecutándolo como si fuera una prueba unitaria normal y corriente. Si todo funciona correctamente, en la salida por consola verás indicaciones de que nos e han encontrado las implementaciones de los pasos de los escenarios de la calculadora.
Implementaciones de los pasos.
Para poder conectar los pasos del escenario con el sistema bajo prueba es necesario indicar a Cucumber qué código debe ejecutar para cada paso. Este código se indica en métodos y cada método se etiqueta para saber a qué paso corresponde.
Para encontrar la implementación de pasos copia el archivo RpnCalculatorStepdefs.java
Código bajo prueba
Ya hemos terminado con todo lo necesario para poder ejecutar los escenarios en Cucumber. Sin embargo aún queda añadir el código bajo prueba, en este caso el código del calculador.
Para ello, muévete aquí y copia el fichero RpnCalculator.java a tu proyecto.
Todo junto
Vuelve a ejecutar tu runner. Ahora deberías ver información por la salida estándar de los escenarios y los pasos ejecutados. Prueba a cambiar algo de código en el fichero RpnCalculator.java y comprueba cómo algunos escenarios dejan de funcionar.
Y esto es todo, nos vemos el lunes en el dojo.
Charla sobre TDD que tuve la oportunidad de dar en el GDG DevFest Sur de octubre de 2.013
Un compañero ha preparado un resumen de la charla y el dojo del próximo martes 13 en la EPS de Almería.
¡¡Gracias!!
Me han invitado a participar como miembro del jurado del hackathon del proyecto europeo HOMER que se desarrollará de forma simultánea en seis regiones de 5 países: Italia, Grecia, Francia, Montenegro y España.
HACK4MED comienza el sábado 17 de mayo 2014 y finaliza el domingo 18 de mayo 2014. en horario ininterrumpido desde las 9:00h del sábado a las 16:30 del domingo (hora española).
Escribiré una crónica detallada cuando vuelva. Suerte a todos.
Jueves 29 de mayo. #IWT2 DojoUS dedicado a BDD.
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.
Nos vemos el lunes.
¿Cómo enseñar TDD? Cosas que hago y cosas que busco mejorar
Este mes ha sido muy especial. A principios de mes el equipazo de Oxik Studio me propusieron facilitar un dojo en sus instalaciones dónde nos lo pasamos genial, y el pasado miércoles 23 de abril me invitaron a facilitar un dojo de código para aprender Test-Driven Development (o TDD) en el centro de co-working CoLaborando .
Contamos con la asistencia siete valientes muy motivados que fueron capaces de hacer dos ciclos de TDD (rojo, verde, refactorizar) completos con la kata FizzBuzz, en Java y con Eclipse. El primer ciclo fue guiado paso a paso utilizando la plantilla que tienes aquí debajo, y el segundo ya por su cuenta.
La fenomenal experiencia de estos dojos confirma lo que vengo notando en otros dojos, conferencias y charlas con gente: enseñar TDD es difícil. Sigo intentando mejorar la manera de facilitar el primer paso de la gente a TDD. Algunas ideas que ya estoy usando las cuento a continuación.
La ficha ha sido una buena idea: transite qué tienes que hacer en un ciclo de TDD y te para los pies si quieres abarcar demasiado de golpe (error típico). También ayuda a tener más claro qué cosas hay que refactorizar antes de pasar a la siguiente prueba.
Además, he utilizado otra ficha para facilitar las retrospectivas y que los asistentes se la puedan llevar y reutilizar si quien completar la kata o seguir trabajando con ella. Tenéis esta plantilla justo a continuación.
Preparé un ejemplo de código, no de la kata preparada, sino de cómo sería un método main que utilizara el código para enseñarlo al final del dojo. Este método main enseña cómo hemos identificado código similar, como lo hemos refactorizado y cómo sería posible añadir un nuevo requisito (por ejemplo cambiando el 7 por otra cadena) sin modificar nada del código ya creado, sino simplemente añadiendo nuevo código.
Sin embargo lo anterior no es suficiente. Aún hay algunas cosas que se pueden mejorar.
He descubierto que me cuesta muchísimo programar y hablar al mismo tiempo, así que si quiero hacer una kata presentación e ir mostrando paso a paso un ejercicio, tengo que prepararlo muy, muy bien.
A pesar de que en TDD se escriben pruebas constantemente, muchas personas se acercan a los dojos sin tener apenas idea de cómo diseñar una prueba, utilizar JUnit o, simplemente, qué es y qué no es una prueba. Así que tengo que buscar la manera de transmitir la filosofía de las pruebas unitarias a la misma vez que TDD y sin extenderme demasiado.
También hay algunos detalles que da la experiencia (o el leer muchísimo sobre TDD) que tengo dudas de si introducirlo. Por ejemplo escribir pruebas unitarias con la técnica de Assert First insistir más en la refactorización de las pruebas para evitar que un cambio en el código implique cambiar muchas pruebas unitarias.
Con frecuencia, me hacen preguntas que no tienen que ver con TDD sino que son temas de requisitos, organización e equipo, patrones de diseño, etc. Siempre dejo claro que TDD es una técnica para escribir código y para organizar bien dicho código pero eso no es suficiente. Tengo que darle vueltas a la manera de presentar TDD no como una parte aislada, sino como una pieza de la maquinaria de desarrollo de software, sin caer en el error que eso me lleve a dar una clase magistral de 1 horas sobre ingeniería del software.
Quiero buscar algún plug-ind de Eclipse que permita obtener feedback de cómo se está aplicando TDD, pero este es un tema extenso y lo dejo para otra entrada.
Y además de todo lo anterior, tengo pendiente retomar mi libro sobre TDD, que tengo algo olvidado para rehacerlo teniendo en cuenta todas estas ideas que he puesto en los párrafos anteriores.
Si quieres saber qué nuevas ideas voy aplicando para enseñar TDD vente al próximo dojo. Si estás endiente de la estupenda web de Sur Código seguro que no te lo pierdes.
Dojo de código para aprender TDD el próximo miércoles 23 de abril
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.
Los asistentes pueden usar el lenguaje y herramienta que quieran. el facilitador proporcionaráá ejemplos en Java / Eclipse y en Python / Pycharm.
After-kata, la S de SOLID y una única reponsabilidad
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.
Hasta pronto.
Cuando desarrollar juegos pasa de sueño a pesadilla tienes varias alternativas. Una de las mejores es preguntarle a un japonés que haya trabajado en Toyota y p
Entrada que escribí para la sección de firmas invitadas del estupendo blog IndieOrama contando mis experiencias desarrollando juegos aplicando Test-Driven Development.
No solo me lo pasé genial trabajando con ellos sino que tuvieron el detallazo de diseñar un banner original que es el que está en la cabecera de este blog. ¡¡¡ Gracias !!!
Si alguna vez te has sentido infeliz escribiendo código y desarrollan software, o participando en un proyecto, no estás solo. Desde hace más de cuarenta años personas que también sintieron eso y que creen que debe existir algo mejor han invertido...
Me han invitado a escribir un artículo en OpenWebinars.net sobre TDD y su relación con el mundo ágil y aquí lo tenéis.
Muchas gracias al equipo de OpenWebinars por la invitación.
Crónica del #IWT2 DojoUS y la kobuto kata REST-Consumer
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
Cómo aislarnos de las dependencias del sistema. Un caso práctico con Python, MagicMock y TDD
Python, TDD, Mocks y Github en el próximo #IWT2 DojoUS en Sevilla.
Me apasiona probar cosas nuevas (de programación, no pensemos mal). Herramientas, librerías, arquitecturas, etc. También busco que todo lo anterior me vaya llevando cada vez más cerca del buen diseño, el trabajo agradable y divertido y la sensación de estar construyendo algo equilibrado y armonioso. Sí, eso es lo que veo en el código.
Para animarme a mí mismo a salir de mi zona de confort y conocer personas con aficiones similares empecé el 2.013 un dojo de código, el #IWT2 DojoUS en Sevilla. Este dojo está abierto a todo el que quiera venir a practicar y también a todo el que quiera proponer una práctica. Cualquier cosa que nos empuje a probar algo nuevo o hacer algo mejor es bienvenida.
El próximo 21 de marzo de tendremos una nueva reunión, la 9ª. Esta reunión será especial por un motivo. Trabajaremos solo con Python.
Me gustaría invitar a gente que nunca ha trabajado con Python, ha trabajado poco y nunca ha escrito pruebas, porque ellos son los que más van a aprender disfrutar.
Para conseguir que todos nos sintamos cómodos y podamos practicar y aprender cosas nuevas vamos a dividir el ejercicio (el mismo para todos) en tres niveles.
El primer nivel (nuevo en la ciudad) hará el ejercicio paso a paso conmigo y explicaremos todo lo que vamos haciendo.
Para el segundo nivel se propone una versión simplificada del ejercicio
Para el tercer nivel se propone hacer el ejercicio utilizando mocks y, además una herramienta específica de pruebas que se adapta como un guante al ejercicio propuesto.
Por supuesto puedes ir cambiando de nivel sobre la marcha si así te encuentras más cómodo. Se trata de pasarlo bien y aprender, no de terminar el ejercicio a toda costa.
Si vas a traer tu portátil te recomiendo que traigas instalada la versión de comunidad de PyCharm (además del intérprete de Python, claro). Esta versión es gratuita sin límite de tiempo. PyCharm es un entorno grande y pesado, pero evita que te tengas que preocupar de detalles como la configuración, crear esqueletos de pruebas, ejecutar las pruebas etc. por lo que podremos centrarnos en escribir pruebas y código y ver cómo sería un buen diseño (o uno no muy malo) en Python.
Empezaremos a las 18:00 con el ejercicio, aunque puedes venir a partir de las 17:30 por si quieres empezar a practicar Python. Sobre las 20 pararemos y haremos una puesta en común, viendo ejemplos de código y contrastando ideas.
Puedes inscribirte al dojo en este formulario https://docs.google.com/spreadsheet/viewform?usp=drive_web&formkey=dFhWcS1QSi1fSG8xeFlRTlVadXNfYUE6MA#gid=0
Estad pendientes del blog y de twitter ya que probablemente pongamos algunos ficheros para descargar antes de la sesión. Nos vemos el 21.
Lista actualizada de materiales sobre TDD y prueba
Como adicto a crear cosas a través del código fuente me aficioné con pasión a TDD y similares hace algo más de dos años. Para buscar gente afin y compartir ideas e ido publicando mucho material en este blog, cursos, presnetaciones etc.
En el estupendo grupo de aficionados a Android y Java se Sevilla se puso de manifiesto el interés de los asistentes por saber más sobre TDD, así que me he animado a actualizar el listado de todo lo que he hecho y aquí los tenéis completo (en el grupo no puedo incluirlo todo por el límite de caracteres de los mensajes).
Es mucho más divertido practicar de TDD que leer sobre TDD, que también está bien. Así que quien de verdad tenga ganas que contacte conmigo y nos ponemos un rato a escribir pruebas y compartir ideas.
Que lo disfrutéis.
Libro: Desarrollo Dirigido por Pruebas Práctico
http://es.scribd.com/doc/137055522/Desarrollo-Dirigido-por-Pruebas-Practico
Dojo se código IWT2 DojoUS:
http://www.iwt2.org/web/opencms/IWT2/comunidad/dojous/?locale=es
Materiales de cursos
Actualmente tenemos los materiales de un par de cursos publicados con licencia CC. Puede que no esté todo o que no esté completo, por lo que si tenéis interés en algo comentádmelo.
Sacándole Partido a JUnit
http://www.iwt2.org/web/opencms/IWT2/formacion/catalogo/curso0001.html?locale=es
TDD / Desarrollo Dirigido por Pruebas desde Cero (I Edición)
http://www.iwt2.org/web/opencms/IWT2/formacion/catalogo/curso0006.html?locale=es
Presentaciones en Slideshare
Desarrollo dirigido por pruebas para videojuegos
http://es.slideshare.net/Javier_J/gamwus-desarrollo-diriguido-por-pruebas-y-videojuegos
Programando juegos casuales con desarrollo dirigido por pruebas
http://es.slideshare.net/Javier_J/cas-05
Desarrollo de videojuegos dirigidos por pruebas
http://es.slideshare.net/Javier_J/11-27358601
Aplicando TDD y Jasmine en la creación de videojuegos en JavaScript
http://es.slideshare.net/Javier_J/videojuegos-en-javascript-con-tdd-y-jasmine
Kata tenis paso a paso (y con otras soluciones para comparar)
http://es.slideshare.net/Javier_J/kata-tennis-paso-a-paso
http://es.slideshare.net/Javier_J/kata-aula-teaser
https://github.com/javierj/Python-TDD
TDD y Python (charla de la primera reunión del grupo d eusuarios de Python de Sevilla)
http://es.slideshare.net/Javier_J/tdd-y-python
Kata el juego Sokoban paso a paso
http://es.slideshare.net/Javier_J/iwt2-dojous-05-octubre-2012-ejercicio-sokoban-14670478
https://github.com/javierj/kata-dojous
Introducción a TDD
http://es.slideshare.net/Javier_J/iwt2-dojo-us-introduccin-a-tdd-5-octubre-2012
Ejemplos de TDD, BDD, Mocking y Kata tenis
https://github.com/javierj/Python-TDD
Entradas en el blog (ordenadas de la más actual a la más antigua)
Crónica del último DojoUS de 2013 sobre dobles de prueba
http://iwt2-javierj.tumblr.com/post/73196572533/cronica-del-ultimo-dojous-de-2013-sobre-dobles-de
Cómo aislarnos de las dependencias del sistema. Un caso práctico con Python, MagicMock y TDD
http://iwt2-javierj.tumblr.com/post/67646801575/como-aislarnos-de-las-dependencias-del-sistema-un-caso
Crónica #IWT2 DojoUS 08 de noviembre. Kata números romanos
http://iwt2-javierj.tumblr.com/post/66678869217/cronica-iwt2-dojous-08-de-noviembre-kata-numeros
Las claves de TDD en DevFest Sur
http://iwt2-javierj.tumblr.com/post/65706987128/las-claves-de-tdd-en-devfest-sur
Publicando TDD y Pyhton en el blog de Pybonacci
http://iwt2-javierj.tumblr.com/post/54099001271/publicando-tdd-y-pyhton-en-el-blog-de-pybonacci
Materiales sobre Test-Driven Development (TDD)
http://iwt2-javierj.tumblr.com/post/53054249843/materiales-sobre-test-driven-development-tdd
#IWT2 DojoUS. Último dojo del curso. Viernes 28 de junio de 18:30 a 20:30
http://iwt2-javierj.tumblr.com/post/52041654469/iwt2-dojous-ultimo-dojo-del-curso-viernes-28-de
Crónica de la presentación: Aplicando TDD y Jasmine en la creación de videojuegos en JavaScript y enlaces adicionales
http://iwt2-javierj.tumblr.com/post/50760915739/cronica-5-sevillajs-16-05-2013
Retrospectiva y autocrítica de la charla de TDD en la primera reunión Python-Sevilla
http://iwt2-javierj.tumblr.com/post/37025295658/retrospectiva-y-autocritica-de-la-charla-ptdd-y-python
Resumen del #IWT2 dojoUS dedicado a la kata Sokoban:
http://iwt2-javierj.tumblr.com/post/34220121640/resumen-del-iwt2-dojous-5-de-octubre-kata-sokoban
Solución de la kata cifrado Cesar paso a paso aplicando JavaScript y Jasmine
http://iwt2-javierj.tumblr.com/post/37905296603/kata-cifrado-cesar-paso-a-paso-en-javascript-jasmine
Un ejemplo de ATDD / BDD con Python y Behave
http://iwt2-javierj.tumblr.com/post/36762766836/atdd-bdd-con-python-y-behave-previa-python-tdd
Un ejemplo de Mocks en Python (con Mockito y MagicMock)
http://iwt2-javierj.tumblr.com/post/36695988608/mocks-en-python-previa-python-tdd
Solución paso a paso del algoritmo de la criba de Eratóstenes aplicando TDD (en Java)
http://iwt2-javierj.tumblr.com/post/36500513493/test-driven-development-practico-algoritmo-de-la-criba
ATDD, pruebas de videojuegos y el patrón Modelo-Vista-Controlador
http://iwt2-javierj.tumblr.com/post/35068699479/atdd-pruebas-de-aceptacion-videojuegos-y-mvc
Solución de la kata de noviembre (SQL String Generator) utilizando Lua
http://iwt2-javierj.tumblr.com/post/34920088049/kata-test-driven-development-de-noviembre-utilizando
GitHub
Pick’A’Gem. Juego en Javascript desarrollado con TDD (aunque no muy estricto)
https://github.com/javierj/PickAGem
Nelbe. Juego en Java desarrollado con TDD (aunque no muy estricto)
https://github.com/javierj/Nelbe
Kata cifrado César en Javascript
https://github.com/javierj/Test-Driven-Development
Entradas en otros blog (ordenadas de la más actual a la más antigua)
Assert First, o por qué empezar escribiendo los asserts de tus pruebas
https://aprendiendotdd.wordpress.com/2013/11/06/assert-first-o-por-que-empezar-escribiendo-los-asserts-de-tus-pruebas/
Triangular un fake, un error a evitar
https://aprendiendotdd.wordpress.com/2013/07/07/triangular-un-fake-un-error-a-evitar/
Desarrollo Dirigido por Pruebas en Python (III). Independencia del Sistema
http://pybonacci.wordpress.com/2013/12/03/desarrollo-dirigido-por-pruebas-en-python-iii-independencia-del-sistema/
Desarrollo Dirigido por Pruebas en Python (II). Un Caso Práctico (I)
http://pybonacci.wordpress.com/2013/06/19/desarrollo-dirigido-por-pruebas-en-python-ii-un-caso-practico-i/
Introducción a TDD y Python
http://pybonacci.wordpress.com/2013/01/07/desarrollo-dirigido-por-pruebas-en-python-i-una-historia-que-pasa-todos-los-dias/
Testing en General
Aislándonos de las dependencias del sistema en Java. Tres ejemplos con Mockito y PowerMock
http://iwt2-javierj.tumblr.com/post/70699841180/aislandonos-de-las-dependencias-del-sistema-en-java
Analizando Scikit-Aero (en Python 2.x)
http://iwt2-javierj.tumblr.com/post/69258809610/analizando-scikit-aero-en-python-2-x
No tienes que empezar por la base de datos. El ejemplo FitNesse
http://iwt2-javierj.tumblr.com/post/68893830739/no-tienes-que-empezar-por-la-base-de-datos-el-ejemplo
Testing Unitario con Microsoft Fakes (reseña del libro)
http://iwt2-javierj.tumblr.com/post/65777544145/testing-unitario-con-microsoft-fakes-resena-del-libro
Testing en la Conferencia Agile Spain 2.013
http://iwt2-javierj.tumblr.com/post/64211981156/testing-en-la-conferencia-agile-spain-2-013
¿Es útil una prueba que no prueba nada? Sobre pruebas para ganar en seguridad o para documentar el código.
http://iwt2-javierj.tumblr.com/post/51991501684/es-util-una-prueba-que-no-prueba-nada
Proyecto Android Testing Snippets
http://iwt2-javierj.tumblr.com/post/50997901913/proyecto-android-testing-snippets
https://github.com/javierj/android-test-snippets
Introducción al API de testing en Android
http://androcode.es/tag/testing/
Introducción a las pruebas en Android
http://es.slideshare.net/Javier_J/testing-en-android-03
Mejorando la testa8ibilty de una librería RSS
http://iwt2-javierj.tumblr.com/post/49867076288/mejorando-la-testability-de-una-libreria-de-rss-para
Listas palíndromas con Python (y Behave), Java y Lua
http://iwt2-javierj.tumblr.com/post/48353809470/listas-palindromas-solucionado-en-python
Ejercicio de prueba de código (con gatitos)
http://iwt2-javierj.tumblr.com/post/48118075108/ejercicio-o-pasatiempo-de-pruebas-del-codigo
Extendiendo Jasmines para que las pruebas de vieeojuegos sean más visuales
http://iwt2-javierj.tumblr.com/post/44304796217/extendiendo-jasmine-para-tdd-bdd-visual-de-videojuegos
Notas sobre nombres descriptivos para casos de prueba
http://iwt2-javierj.tumblr.com/post/42021785848/notas-sobre-nombres-descriptivos-para-casos-de-prueba
Resumen del #IWT2 dojoUS dedicado a principios SOLID y GRASP
http://iwt2-javierj.tumblr.com/post/35781055793/resumen-del-iwt2-dojous-9-de-noviembre-principios