El martes pasado participé del dictado de este taller junto con @jgabardini. Me gusto como salió, pero al igual que en otras ocasiones, creo que nos quedamos cortos en el tiempo de práctica.
Durante el taller trabajamos con las siguientes herramientas:
Adicionalmente también hablamos sobre:
La evaluación de los asistentes fue muy buena y adicionalmente me surgieron algunas ideas para probar en próxima ediciones.
La semana pasada en el contexto del trabajo final de Algo3 dimos la clase de MVC de cara a que los alumnos puedan empezar a trabajar en la parte de vista y controlador. A los poco días recibí un mail de un alumno de uno de mis grupos con la siguiente consulta:
Queríamos consultarle si hay alguna forma apropiada de hacer testing para la parte de vista del proyecto, ya que desde que nos pusimos a trabajar con la misma la cobertura de código del proyecto bajó notablemente.
Sinceramente la consulta me sorprendió para bien y me causó una gran satisfacción ver que un alumno tenga este tipo de inquietudes ya desde los primeros años de la carrera.
Este es un tema que vengo trabajando desde hace tiempo. Como parte de mi carrera fue muy poco lo que ví al respecto. Vi algo de prueba unitaria en la materia de objetos. Tuve una materia de calidad (Calidad en desarrollo de software) que me resultó muy interesante, pero que estaba más enfocada en cuestiones de proceso, por lo cual fue muy poco lo que vimos de pruebas.
Más allá de eso, mi actividad profesional me llevó a ir metiéndome en el tema. Por un lado, el trabajar con prácticas ágiles de ingeniería me llevó a meterme en temas de automatización de pruebas funcionales/de regresión. Por otro lado, el trabajar como consultor revisando/diagnosticando aplicaciones, me llevo a interiorizarme en cuestiones de pruebas de stress. Luego, inquietudes personales me llevaron a reforzar un poco más la parte teórica. Finalmente, este último año que he estado trabajando en cuestiones de continuous delivery profundicé en cuestiones de automatización de prueba con distintas herramientas.
Más allá de las cuestiones académicas, tengo la percepción que parte de la industria no toma seriamente el testing. He visto muchas empresas que ven a las personas que hacen testing como «ciudadanos de segunda clase». En esos contextos, las personas que hacen testing, son los que menos cobran, los que «menos saben» y los que menos requisitos tienen para acceder al puesto. Esas mismas empresas son las que suelen hacer casi todo su testing en forma manual.
En cierto modo esto plantea el dilema del huevo o la gallina: «La academia no presta atención al testing porque la industria no lo considera relevante o la industria no pone foco en testing avanzado porque la academia no prepara profesionales en testing».
Luego de algunas charlas de intercambio mantenidas durante Agiles 2013 me decidí a hacer algo al respecto de la situación aquí descripta. Por un lado, empecé a trabajar en conjunto con mis colegas de Kleer (más particularmente con JuanG) para dictar una serie de Talleres de Pruebas automatizadas. Por otro lado, en el contexto académico, tengo la intención de dictar una materia de Testing junto con PabloT en UNQ.
Algo de todo esto voy a estar presentando el sábado próximo en el contexto de mi sesión en el Workshop 2013 de Uqbar.
Una confusión que muy frecuentemente encuentro es el uso del término QA para referirse a cuestiones de prueba. Voy a intentar aclarar un poco esta confusión.
Existen diversas definiciones de calidad. Una de ellas es la que define calidad como ausencia de defectos. Esto nos lleva a definir qué entendemos por defecto. En términos generales podríamos decir que un defecto es una no conformidad con los requerimientos/especificaciones.
El testing es una actividad enfocada en la detección de defectos. El testing por si sólo no asegura la calidad de un producto. Decir que al testear se mejora la calidad de un producto, sería equivalente a decir que por pesarse se baja de peso. El testing brinda información sobre los defectos de un producto, del mismo modo que una balanza brinda información sobre el peso. Luego en base a esa información uno puede tomar acciones correctivas, como hacer dieta en el caso de sobrepeso, o corregir los defectos en caso que estos sean de una severidad no aceptable. En términos más formales el testing es denominado Quality Control (QC).
Ahora bien, testear para detectar defectos y luego corregirlos, es un enfoque de calidad en cierto modo reactivo. Esto nos lleva a la pregunta: ¿podremos hacer algo más proactivamente para asegurar la calidad de nuestros productos?
Si aceptamos que la calidad del producto está influenciada por el proceso de construcción del mismo, entonces podríamos tomar un enfoque de calidad más proactivo, definiendo tareas en nuestro proceso de cara a asegurar la calidad. Esto es precisamente lo que se denomina aseguramiento de calidad o simplemente QA (Quality Assurance).
Entonces, siendo explícito: el aseguramiento de calidad (QA) tiene que ver con procesos, no con testing. Claro que existe cierta relación entre estas dos actividades, pero también es cierto que cada una de estas actividades requiere de distintas habilidades.
Resumiendo:
QA = Quality Assurance = Aseguramiento de calidad -> Procesos
QC = Quality Control = Control de calidad -> Testing
Una cuestión clave en todo contexto de continuous delivery son las pruebas automatizadas. De poco sirve pasar «rápido» entre ambientes, si no podemos garantizar cierta calidad de lo que estamos poniendo en cada ambiente.
Cuando uno construye aplicaciones desde cero, es relativamente fácil generar pruebas automatizadas. El uso de técnicas como BDD y TDD junto con algunos patrones de diseño permiten generar aplicaciones testeables y con alto nivel de cobertura.
Pero no siempre trabajamos sobre aplicaciones nuevas. En ocasiones nos toca trabajar con aplicaciones ya existentes, que muchas veces no cuentan con pruebas y que han sido desarrolladas sin tener en cuenta la testeabilidad. En los contextos ágiles a este tipo de aplicaciones se les suele llamar aplicaciones legacy.
Por suerte son pocos los proyectos, en los que trabajando como programador, he tenido aplicaciones legacy. Sin embargo, trabajando como consultor, me he cruzado bastante a menudo con clientes llenos de este tipo.
Mi estrategia para trabajar con aplicaciones legacy es comenzar haciendo algunas pruebas funcionales que cubran los principales flujos de la aplicación. Y luego a gradualmente comenzar a modificar la aplicación haciendola testeable y agregando distintos tipos de tests según sea posible.
Una combinación de herramientas que me ha resultado interesante para hacer pruebas funcionales es SeleniumIDE + TestNG.
Selenium IDE es una herramienta de automatización de pruebas del tipo Record & Play que funciona integrada con el explorador FireFox y permite que uno vaya recorriendo la aplicación y poniendo aserciones en determinados puntos. Luego la misma herramienta permite reproducir la prueba grabada. Si bien a primera vista la estrategia puede parecer muy interesante, la realidad es que no es tan simple. De hecho este tipo de herramientas de automatización de pruebas ha tenido varias críticas (algunas de las cuales comparto), por diversos motivos que han sido tratados, entre otros, por George Meszaros.
Por su parte TestNG, es una herramienta al estilo JUnit, pero a diferencia de esta, tiene un foco más amplio que la prueba unitaria y por ello provee algunas funcionalidades muy útiles para hacer pruebas funcionales.
A partir de estas dos herramientas, mi estrategia es:
Dos cuestiones importantes a considerar para utilizar este enfoque y que son las que abarca el punto 5 son:
Bien, esto es todo por el momento.
Como siempre, si tienen alguna consulta/inquietud, no duden en escribirme.
Continuando con el tema pruebas, es hora de hablar de las pruebas no-unitarias.
Estas pruebas buscan probar componentes en forma NO aislada. Pero no son necesariamente pruebas de usuario. Hay ciertos casos donde es muy costoso aislar un componente para su prueba o que incluso, puede que no tengas sentido ese aislamiento pues la parte crítica radica justamente en la integración.
Son las pruebas que definirán si hemos completado o no una story dada. Son naturalmente pruebas de integración, ya que no prueban un componente aislado sino también la interacción de varios componentes (son no-unitarias).
Estas pruebas sí son de la incumbencia del usuario, por eso es que intentamos hacerlas con alguna herramienta que le resulte cómoda al usuario (que en general no es una persona técnica).
En nuestro caso usaremos Cucumber. Cuando hacemos BDD estamos haciendo este tipo de pruebas.
Nuestro foco con estas pruebas es asegurarnos que entendimos bien la story y que el código que escribimos hace lo que tiene que hacer. Como consecuencia de esto no debería ser relevante donde ejecuto las pruebas. O sea, no es necesario instalar la aplicación en un ambiente particular para ejecutar estas pruebas. Al mismo tiempo, podría en algunos casos escribir steps de cucumber que manipulen directamente los objetos de mi modelo.
Estas pruebas son similares a la anteriores, pero adicionalmente también queremos asegurarnos que la aplicación fue correctamente configurada y que todo su ecosistema está perfectamente funcional. Esto implica que sí es relevante el lugar donde pruebo la aplicación. Debería ser un ambiente similar al de producción.
Aquí ya no estamos hablando de hacer BDD. Respecto de las herramientas, puedo usar un robot tipo Selenium o VSTest o incluso Rspec. Es más, mucha gente hace estas pruebas en forma manual.
También puedo utilizar cucumber, pero con algunas restricciones:
Muchas veces estas pruebas se hacen en forma manual. El equipo termina el desarrollo, instala la app en un ambiente de test y un equipo de testers ejecutar pruebas a modo «caja» negra.
Continuará….
Ayer recibí una consulta sobre este tema y estaba convencido que ya tenia algo escrito al respecto. Me puse a buscar me encontré con este post que había escrito hace ya más de un año, pero nunca había publicado no recuerdo por qué.
Continuando con este post que hice hace un tiempo, hoy quiero compartir algunos pensamientos. Personalmente creo que es importante tener un alto grado de cobertura, pero no hay que perder de vista que la cobertura sólo indica que el código ha sido ejercitado, pero nada dice de cuan bien (o cual mal) ejercitado. Precisamente hace unos dias Carlos me compartió este artículo donde se hace especial incapié en este punto.
Como lo indica este artículo que compartí anteriormente, existen distintos tipos de cobertura. Puntualmente la forma de cobertura que yo describí entra en lo que se describe como statement coverage y que es lo que mide la gran mayoria de las herramientas.
Pero esto sólo, es una herramienta insuficiente y si uno no analiza los resultados con criterio, podria llegar a engañarse facilmente.
Es cierto que de no tener pruebas, a tener pruebas que ejerciten el 80% del código, es una mejora muy importante, pero de ahí a «confiarnos» en la calidad de nuestro código, hay aún un trecho interesante por recorrer y posiblemente sea el trecho más complejo. Es más, dado el esfuerzo que puede implicar ese 20% restante, puede que resulte más conveniente, concentrarse simplemente en las partes del código que suelen tener acarreados más defectos.
Continuará…
Hace un tiempo en un webcast de la comunidad ágil de Venezuela mencioné la importancia de que todo programador sea responsable de escribir las pruebas unitarias de su código, lo cual es absolutamente independiente del lenguaje de programación utilizado ya que para hacer pruebas no es necesario contar con ninguna herramienta particular. Ante esta afirmación una persona de la audiencia consulto ¿afirmas que es posible escribir pruebas unitarias sin usar un framework de pruebas unitarias? La respuesta es si. Veamos un ejemplo.
Básicamente una prueba unitaria consta de 3 pasos conocidos como las 3A.
De estos tres pasos el único que depende del framework de pruebas unitarias es el assert. Generalmente el framework de pruebas unitarias provee uno o varios métodos del tipo assertXXXX que verifican el valor de verdad de una expresión y en base a ello arrojan un resultado.
Esta funcionalidad del assert de framework de pruebas unitarias bien podría ser reemplazada por una función similar a la siguiente
public void verificar(boolean expresion){
if(!expresion)
throw new RuntimeException();
}
Vemos cómo podríamos utilizar esta función para hacer un prueba de la clase ArrayList.
public void deberiaCrearseVacio(){
// arrange & act
ArrayList array = new ArrayList();
// assert
verificar(array.size()==0);
}
Para aquellos interesados en profundizar, aquí les dejo un ejemplo completo en Java que muestra como codificar y ejecutar las pruebas.
¿Llegará el día en que escuche a una presentación de Juan y no aprenda nada? No lo sé, pero lo veo difícil. El martes tuve agrado de asistir al encuentro mensual de comunidad Agiles@ Buenos Aires donde Juan dió una presentación titulada: ¿Existe «la mejor manera» de probar?. Simplemente excelente: no solo la presentación fue muy buena sino que también me resultó enriquecedora la ronda de preguntas y respuestas.
Otro punto para destacar es la importante cantidad de asistentes (muchos de ellos primerizos en estos encuentros) sobre considerando que estamos en pleno período de vacaciones.
La sesión fue grabada, con lo cual dentro de un tiempo seguramente este disponible en el blog de Juan o en el sitio de comunidad, pero mientras tanto pueden leer este blogpost de Juan que resume lo presentado.
Aquí les dejo algunas fotos del evento.
Blog de NicoPaez 