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

#ConstrucciónDeSoftware, disponible en Amazon

La semana pasada cumplimos un nuevo hito con el libro, llegamos a Amazon. El libro puede encontrarse fácilmente buscando por “construccion de software” o directamente siguiendo este link.

Cabe aclarar que por el momento sólo es posible comprar la versión física del libro, la versión digital para Kindle aún no está disponible, estamos trabajando para ella pero va a llevar un tiempo más.

libroenamazon

Galería

Galeria fotos de Agiles 2014

Galería completa aquí.

Fer di Bartolo en su sesión Transformation Priority Premise

Fer di Bartolo en su sesión Transformation Priority Premise

Hernán y Jorge de 10 Pines en el almuerzo

Hernán y Jorge de 10 Pines en el almuerzo

Dos tipos duros, Diego Garber de OLX y Carlos Peix de Kleer

Dos tipos duros, Diego Garber de OLX y Carlos Peix de Kleer

Juan, Diego y Gerardo, de Uruguay

Juan, Diego y Gerardo, de Uruguay

Con Diego Fontdevila y Mauro Cesar luego de la sesión de "Buen desarrollo sin agilidad"

Con Diego Fontdevila y Mauro Cesar luego de la sesión de “Buen desarrollo sin agilidad”

DSC04723

Carlos Hurtado y Jugel Correa contando su caso en Sura

Sesión de LeanUX facilitada por Olga Cardenas

Sesión de LeanUX facilitada por Olga Cardenas

En la presentación del libro Diego Fontdevila y Juan Gabardini

En la presentación del libro Diego Fontdevila y Juan Gabardini

Agiles 2014, DONE

Ayer finalizó Ágiles 2014. Fueron 3 días muy intensos. No tengo números oficiales, pero sin duda hubo un record de asistencia, se rumoreaba por los pasillos que había alrededor de 700 asistentes. Según pude confirmar hubo asistentes de 10 países: Colombia, Argentina, Perú, Ecuador, Chile, Uruguay, El Salvador, USA, Bolivia y Brasil.

Manteniendo la tradición de años anteriores, el evento estuvo organizado en 2 dias de conferencias tradicionales y un dia de Open Space. En este sentido fue el open space más grande del que participé. Los facilitadores del mismo fueron Luis Mulato y Carlos Hurtado. Dejando de lado los keynotes, creo que en promedio las mejores sesiones estuvieron en el open space.

Si bien hubo sesiones muy buenas, como el keynote de Martin Alaimo y la sesión de LeanUX de Olga Cárdenas, creo que hubo unas cuantas que fueron muy pobres. Definitivamente este es un tema a mejorar en el futuro.

Un condimento adicional de esta edición de Agiles fue la presentación de dos libros: Por un Scrum Popular, traducción con anotaciones de Alan Cyment del libro Tobias Meyer y Construcción de software, mi libro ;-).

Inicialmente la idea de realizar el evento en un hotel de alta categoría me generó cierto ruido pero debo admitir que la “experiencia de asistente” fue excelente y en mi caso particular se vio potenciada por el hecho de alojarme en el mismo hotel.

Agradezco al equipo organizador por regalarnos este gran evento y darle continuidad a este espacio que inauguramos allá por 2008.

El próximo año el evento se realizará el Montevideo, allí nos veremos Ágiles 2015 Uruguay.

openspaceagiles2014

Marketplace del Open space

 

Agiles 2014, mi presentación sobre automatización de pruebas

Esta mañana di mi sesión sobre pruebas automatizadas. La sala estaba repleta de gente a punto tal que había gente sentada en el piso. Estimo había cerca de unas 80 personas.

Dado que yo ya sabía que no tendría tiempo suficiente para compartir todo el contenido que tenía preparado, compartí esto en con la audiencia y los invité a priorizar los temas a tratar: teoría de automatización y demostraciones de herramientas. Finalmente acordamos comenzar por los temas teóricos y dejar las demos para una sesión del open space de mañana.

Más de la mitad de los asistentes eran de perfil técnico (programadores y testers) y sólo una pequeña parte (unos 10) tenían pruebas automatizadas.

El material utilizado está disponible para descarga aquí.

sesion_agiles_2014

Clase en el posgrado de la UCA

La semana pasada dicté una clase sobre Extreme Programming en el contexto de la especialización en Ingeniería de Software de la UCA. Más concretamente la clase fue en el contexto de la materia Métodos de desarrollo de Software que dicta Andrés Diaz Pace.

Previamente Mariano Tugnarelli había dado una introducción a los métodos ágiles y Scrum. Lo cual preparó el contexto para meternos con XP.

El grupo de alumnos resultó ser bastante heterogéneo, varios de ellos trabajando activamente en el sector de software, algunos electrónicos, algunos graduados recientemente y otros hace ya bastante, en su mayoría Argentinos, pero también varios extranjeros. Muy poco con conocimientos de métodos ágiles.

Inicialmente hicimos una actividad de mitos y verdades la cual nos sirvió de disparador para ir entrando en varias conceptuales.

Algunos recursos interesante relacionados a los que vimos en la clase:

agiles_uca