Mes: noviembre 2014

Experiencias de Enseñanza de POO en WISIT 2014

El sábado pasado estuve participando del WISIT 2014. Junto con Pablo Suárez presentamos el enfoque estamos utilizando en FIUBA para enseñar Programación Orientada a Objetos.

En nuestra sesión destacamos 4 puntos que consideramos centrales en nuestro enfoque:

  • Uso de técnicas de educación centrada en el alumno (Learner Centered Teaching)
  • Uso de herramientas informáticas: Campus Virtual de la universidad, Foros, Sistema de gestión de TPs (alfred) y videos explicativos.
  • Uso de dos lenguajes: Smalltalk y Java
  • Test-Driven: no solo enseñamos y usamos TDD, sino que también el desarrollo de los trabajos tiene algo de TDD pues las especificaciones de los que los alumnos deben resolver, la entregamos siempre en forma de pruebas.

Creemos que la presentación salió muy bien y notamos a la audiencia muy interesada. De hecho al finalizar nuestra exposición recibimos varias consultas y más de una persona manifestó intenciones de probar Alfred.

Para facilitar la sesión sesión utilizamos un Prezi que armó Pablo y que está disponible aquí. También armamos este póster que enviamos en su momento a los organizadores del evento como parte de nuestra propuesta de sesión.

Curiosamente hubo otras dos sesiones en las que también se presentaron enfoques de enseñanza de POO. Una de esas sesiones estuvo a cargo de Alfredo Sanzo y Lucas Spigariol quienes contaron su enfoque fuertemente basado en actividades de representación/actuación y en el uso de objetos físicos.

La otra sesión sobre POO estuvo presentada por Nico Passerini, Javi Fernández y Pablo Tesone, quienes mostraron Wollok, una herramienta basada en Eclipse y un lenguaje desarrollado por ellos mismo con el fin específico de enseñanza de POO.

Ambos enfoques me parecieron muy interesantes.

Celebro la iniciativa Uqbar Project de llevar adelante este evento. ¡Que se repita!

Selección de herramientas de prueba (parte 1)

Una de las decisiones a tomar al querer hacer pruebas automatizadas es qué herramientas utilizar. Para poder tomar esta decisión resulta importante entender mínimamente la arquitectura de una infraestructura de pruebas automatizadas. El siguiente gráfico resumen de forma muy general una arquitectura de modelo para esta problemática.

arq_pruebasSi bien el gráfico puede sugerir una arquitectura de capas, la misma rara vez se cumple a nivel de implementación pero si es cierto que para elemento representa un nivel de abstracción distinto en la estructura de la solución.

En el nivel de abstracción de más alto tenemos un lenguaje de especificación que nos permite expresar la prueba.
Un ejemplo de un lenguaje posible de especificación podría ser Gherkin.

En un segundo nivel tenemos un intérprete de ese lenguaje
que nos permitirá relacionar la especificación abstracta con fragmentos de código que escribiremos nosotros y que comúnmente se denominan «glue code».
Para el caso Gherkin tenemos como intérpretes las familia de herramientas Cucumber, en particular si quisieras escribir nuestro código en Java podríamos utilizar Cucumber-JVM.

En el tercer nivel tendremos un componente que denominamos **driver** que nos permitirá interactuar con nuestra aplicación. Lo que hace el driver en concreto es implementar el protocolo de comunicación necesario para interactuar con el sistema bajo prueba.
Siguiendo con el ejemplo anterior y asumiendo que el sistema bajo prueba es de tipo web, podríamos entonces utilizar Selenium Web Driver el ofrece una implementación en Java.

El siguiente elemento de nuestra arquitectura es la librería de aserciones, la cual nos permitirá precisamente hacer aserciones sobre el resultado de las operaciones realizadas sobre el sistema bajo prueba.
En este caso es común utilizar alguna librería de la familia xUnit. En el caso de Java utilizaríamos JUnit.

Finalmente, como último ítem de esta enumeración tenemos un motor de ejecución que se encarga de instanciar y ejecutar los elementos previamente mencionados.
En este caso una alternativa muy común en el mundo Java en particular es utilizar el mismísimo JUnit.

En la segunda parte de este artículo ofreceré algunos ejemplos concretos de implementación de esta arquitectura.

¿Realmente necesitas una nueva herramienta para hacer ATDD?

Recientemente recibí una consulta por Twitter sobre este tema y dado que la respuesta no entraba en 140 caracteres decidí escribir este post.

Acceptance Test-Driven Development (ATDD) es una práctica de desarrollo ágil cuya popularidad está en franco ascenso. La idea es simple: guiar el desarrollo de funcionalidades a partir de sus correspondiente pruebas de aceptación. ¿Pero eso no es TDD? Si y no. Conceptualmente ATDD es como TDD en el sentido que es la prueba la guía el desarrollo, pero en general cuando hablamos de TDD estamos hablando del desarrollo de clases, una actividad que realiza el programador. Cuando hablamos de ATDD (o BDD o SBE) hablamos del desarrollo de funcionalidades desde la perspectiva del usuario lo cual requiere del trabajo conjunto del usuario y el programador. Resumiendo:

La principal diferencia entre ATDD y TDD pasa por el involucramiento del usuario en la definición de las pruebas que guiarán el desarrollo y la granularidad de las mismas.

Incluso, hay quienes afirman que el mayor beneficio de ATDD no pasa por la automatización de las pruebas sino por el involucramiento temprano del usuario en la definición de las pruebas de aceptación.

Habiendo dejado en claro los conceptos, vamos a las herramientas. Cuando hacemos TDD escribimos las pruebas en el mismo lenguaje que estamos programando nuestras clases y utilizamos para ello alguna herramienta de la familia xUnit.

Cuando hacemos ATDD escribimos pruebas de funcionalidades desde la perspectiva del usuario e idealmente lo hacemos trabajando en conjunto con él. Esto nos obliga utilizar alguna herramienta de especificación que resulte amena para el usuario quien generalmente no es alguien técnico. Dos herramientas muy difundidas en este terreno son Cucumber y Fitnesse, las cuales ofrecen un lenguaje de especificación muy amistoso y poco técnico. Luego tendremos que escribir lo que se denomina «glue code» para traducir las especificaciones escritas por el usuario a instrucciones ejecutables que se traduzcan en mensaje concretos a nuestro sistema bajo prueba. Este este sentido, puede que esa traducción ocurra a distintos niveles. O sea, una especificación del usuario podria terminar siendo una prueba a nivel de UI o bien una prueba a nivel de servicio o incluso una prueba a nivel de componente o clase. Esto no es un tema menor, ya que tiene un importante impacto en la elección de la herramienta a utilizar.

Si yo pretendo hacer ATDD generando pruebas de aceptación a nivel de componente/clase, entonces deberé elegir una herramienta que esté construida en el mismo lenguaje que mi aplicación. Pero si yo prefiriera hacer pruebas a nivel de UI, entonces tendré más libertad y podré elegir utilizar un lenguaje distinto para programar las pruebas. En este sentido conozco de varios proyectos en Android, .NET y Java, con pruebas de aceptación realizadas con Ruby. Debo admitir que cuando vi esto por primera vez, me resultó chocante, pero luego estuve involucrado en un par de proyectos en que se utilizaba esta estrategia y resultó muy cómodo.

La consulta que disparó este post tenia que ver con herramientas para hacer ATDD cuando la aplicación está construida en .NET. Mi respuesta concreta es:

  • Si el usuario va estar involucrado activamente en la escritura/validación de las pruebas y esas pruebas serán a nivel UI
    => Tienes muchas alternativas pues no estas atado a .Net. Básicamente cualquier herramienta de la familia Cucumber o Fitnesse estará bien.
  • Si el usuario va estar involucrado activamente en la escritura/validación de las pruebas y esas pruebas serán a un nivel por debajo de la UI
    => Puedes usar Specflow o Fitnesse (con su conector para net)
  • Si el usuario no va estar involucrado, entonces tienes libertad total y puedes escribir tus pruebas incluso con algo de la familia xUnit, ya que los únicos que leerán esas pruebas serán los técnicos, pero claro, ya no estarias contando con todos los beneficios de ATDD.

Dicho todo esto: ¿Realmente necesitas una nueva herramienta para hacer ATDD?

Automatización de pruebas y entrega continua en Uruguay

En 25 de noviembre voy a dictar un taller sobre estas temáticas en Uruguay con la colaboración de @pablolis. La idea de hacer un taller que una estas dos temáticas surgió a partir de reiteradas consultas que he recibido y de encontrarme hablando de una de ellas a partir de una consulta que originalmente tenía que ver con la otra.

Ante todo me parece importante dejar bien en claro la relación entre estas dos cuestiones:

  • La automatización de pruebas puede hacerse independientemente de que se trabaje en un contexto de entrega continua. Más aún, ni siquiera es necesario que se trabaje con un proceso de desarrollo en particular. No importa si se trabaja con métodos ágiles, proceso unificado o algún proceso ad-hoc, siempre puede ser valioso automatizar las pruebas.
  • Trabajar en modo entrega continua requiere indefectiblemente contar con pruebas automatizadas, pues de lo contrario, habría que invertir mucho tiempo en pruebas manuales o bien ir a producción con un producto inestable o de calidad desconocida, lo cual podria traducirse en problemas continuos más que en entrega continua.

Con esta aclaración conceptual creo que queda clara la motivación para juntar ambas cuestiones en un mismo taller.

Hablando ahora de la estructura del taller, la idea es comenzar entiendo la práctica de entrega continua, sus beneficios, fundamentos y un conjunto de patrones para su implementación. Todo esto de la mano de un conjunto de herramientas para su implementación. En este sentido compartiremos con los participantes una máquina virtual con una aplicación de ejemplo y con un set de herramientas ya instalado, listo para que puedan poner manos a la obra a medida que vamos viendo las herramientas.

En varios puntos del flujo de entrega continua nos encontraremos con pruebas automatizadas. En cada uno de esos puntos nos detendremos a analizar el tipo de prueba y las distintas alternativas de herramientas para su automatización. Por más que las pruebas y herramientas las veamos en un contexto de entrega continua, como mencioné anteriormente, las mismas también pueden resultar útiles en cualquier otro contexto.

Entre las herramientas que veremos estan: Puppet, Chef, Docker, Jenkins, Go, Travis, Cucumber, Selenium, Fitnesse y JMeter.

Los interesados pueden consultar más detalles e información para inscripción en la página de Evolución Ágil.

#ConstrucciónDeSoftware, entrevista en DevAcademy

Mañana (miércoles 5 de Octubre), a las 22 hs. (Argentina) estaré participando del ciclo DevHangouts organizado por la gente de DevAcademy.

La excusa es hablar un poco del libro: las motivaciones que nos llevaron a escribirlo, el proceso de escritura y obviamente el contenido. Al final del hangout sortearemos un libro.

Los interesados pueden sumarte al hangout via este link: http://devacademy.la/devhangout

Agiles 2014, #NoSeréFeliz pero tengo trabajo

#NoSeréFeliz pero tengo trabajo, fue el título del keynote de Martín Alaimo el tercer día de Agiles2014. Posiblemente haya sido el mejor keynote que vi en las 6 ediciones de ÁgilesXX que participé (no estuve en 2010). Ya de entrada el título resultaba interesante. Más allá del contenido del keynote, destaco algunos elementos que a mi entender fueron claves para que el keynote sea realmente excelente:

  • Manejo de recursos: en primer lugar Martín manejó muy bien los tiempos y respetó lo que estaba agendado. También hizo un uso discreto pero muy apropiado de las diapositivas: diseño minimalista, pocos colores, poco texto, algunas imágenes, nada de transiciones. Esto hacía que audiencia no se distraiga con las diapositivas en cambio prestara atención a lo que Martín decía. También hizo uso de las luces, en un momento se apagaron todas las luces del auditorio lo cual sirvió para generar una atmósfera muy especial y en sintonía con lo .que se estaba hablando.
  • Vivencia: Martín comenzó contando una vivencia personal, lo cual generó una conexión con la audiencia.
  • Participación: a pesar de ser un keynote, Martín hizo participar a la audiencia en varias ocasiones. En un momento nos dió algunas consignas a realizar desde nuestro lugar y luego invitó a algunos voluntarios a subir al escenario.
  • Llamado a la acción: finalmente el keynote cerró con un llamado a la acción, una estupenda idea para el cierre pero que curiosamente pocas veces he visto.

Mientras escribo estas líneas, reflexiono, recorro mi memoria y llego a la conclusión de que este keynote está en el top 3 de las mejores sesión que presencie en mi vida.

¡Gracias Martín!

martin_at_agiles2014