Mostrando entradas con la etiqueta testing. Mostrar todas las entradas
Mostrando entradas con la etiqueta testing. Mostrar todas las entradas

jueves, 30 de junio de 2011

Webinar gratuito: Especificaciones por medio de ejemplos usando FitNesse

Juan Gabardini

El próximo 21 de julio (de 18:30 - 20:00; GMT -3; horario de Buenos Aires) el amigo Juan Gabardini, viejo compañero de aventuras, estará presentando un Webinar (un seminario via web) patrocinado por la buena gente de Kleer.

El tema es el uso de casos de prueba basados en ejemplos utilizando FitNesse, la plataforma de pruebas de aceptación basada en wikis creada por el tío Bob Martin y amigos en base al FIT original de Ward Cunningham (ambas herramientas de código abierto y gratuito).

El evento es en línea y gratuita, pero los interesados deben registrarse porque hay una cantidad máxima de asistentes (aunque no se bien cuál).

La sesión se presentará utilizando GoToMeeting, un servicio de conferencias en línea de Citrix que soporta Windows y Mac OS y utiliza un cliente que se descarga al momento de la conexión, por lo que recomiendo conectarse unos 10 minutos antes para estar seguros de que todo funciona correctamente.

 

El temario, según la invitación, es el siguiente:

FitNesse

¿Cómo logramos que los requerimientos sean claros tanto para los usuarios como para los desarrolladores?


¿Cómo lograr validar continuamente y con bajo costo que el producto cumpla con los requerimientos?


Veremos las especificaciones por medio de ejemplos, una técnica utilizada para lograr estos objetivos, y Fitnesse, una herramienta libre que soporta la técnica.


Fitnesse permite escribir los ejemplos (requerimientos) como tablas o historias, y ejecutar automáticamente estos ejemplos contra la aplicación, informando si la aplicación cumple con los resultados esperados.

 

lunes, 4 de abril de 2011

Page Speed online: una nueva herramienta para medir el rendimiento de sitios web

page speed online

Parte del desarrollo de sitios web de calidad es hacer un análisis correcto de su rendimiento, sobre todo desde temprano, utilizando recomendaciones y técnicas modernas para asegurar un sitio correctamente optimizado. Esto no quiere decir ir en contra de la famosa máxima de Donald Knuth, quien nos ensenó que "la optimización prematura es la causa de todos los males" en programación.

Cualquier sitio web público con una expectativa mínima de tráfico debería responder a una línea base para garantizar una buena experiencia a sus usuarios, y hoy día no necesitamos aplicar técnicas extravagantes o perder mucho tiempo para esto, sino más bien aplicar recursos estándares y sencillos, disponibles en todas las plataformas.

Entre las herramientas para realizar el análisis de rendimiento frecuentemente mencionamos la clásica Firebug (y su plugin YSlow) para Firefox, y Page Speed para Firefox o Chrome. Ambas son excelentes y complementarias, cada una con sus fortalezas, pero ahora Google aporta una alternativa más que puede ser útil en muchas circumstancias: Page Speed online.

A diferencia de las anteriores, en lugar de un plugin, este es un servicio en línea que realiza el mismo tipo de análisis, con lo que podemos ejecutarlo desde cualquier navegador, pero sobre todo puede orientar el análisis sobre navegadores desktop (corriendo en una computadora) como sobre navegadores móviles (sobre todo corriendo en smartphones), para los que incluye algunas reglas específicas como la de eliminar redirecciones en la página inicial que no puedan mantenerse en cache, o reducir la cantidad de Javascript durante la carga de la página. Estas son todas situaciones que no son tan problemáticas en otro ambiente, pero en un teléfono que tiene usualmente un ancho de banda y procesamiento limitados, hacen mucha diferencia.

Veamos un ejemplo. Realicé un análisis para navegadores desktop sobre un sitio popular como Twitter, ingresando la dirección:

page speed Twitter

Y el resultado dio 77 sobre 100 (bastante bueno). El detalle es el siguiente:

Prioridad alta: Estas son reglas que pueden generar mayor impacto en el rendimiento del sitio y que uno debería atacar inicialmente. En el caso de Twitter sólo queda en este nivel la regla: Combinar imágenes como sprites CSS.

Prioridad media: En el siguiente nivel las reglas son: entregar imágenes a escala, optimizar imágenes y minificar Javascript.

Prioridad baja: En este nivel ya hay unos cuantos más. Si quieren pueden ver el informe completo.

Para terminar ejecuto el mismo análisis para la versión móvil de Twitter:

twitter mobile

... y: ¡Oh, sorpresa! me da 100/100. No es de extrañar que Twitter esté muy optimizado para su acceso desde móviles. Así que pruebo con otro servicio que tiene buena tradición en cuando a rendimiento (es donde se empezó a trabajar en estas áreas): http://news.yahoo.com/

El resultado para móviles es de 79/100, que es bastante bueno.

No hay reglas de alta prioridad para atacar, y en las de media, ambas son muy específicas para teléfonos: diferir la interpretación de Javascript y hacer que las redirecciones de la página de inicio puedan mantenerse en cache.

Como siempre, lo importante de estos análisis es leer con atención la información acerca de cada regla, entender de qué se trata y que prácticas tenemos que adoptar de manera permanente para que no vuelva a producirse.

 

lunes, 7 de febrero de 2011

Cómo acelerar nuestras aplicaciones web

High Performance Web Sites

Desde hace ya tiempo la mayoría de las aplicaciones que desarrollamos son aplicaciones web. Incluso el límite entre aplicaciones web y de escritorio es cada vez más difuso, entre nuevas tecnologías basadas en plugins como Flash, Silverlight o Unity, y el incremento de poder del lado de HTML y Javascript, incluyendo también soporte offline y otras características.

Sin embargo, la web, por las maravillas de la diversidad que la hacen fabulosa, también es un océano de calamidades desde el punto de vista del diseño e implementación de las aplicaciones que encontramos en ella.

A esta altura la mayoría de nosotros debería conocer las recomendaciones y herramientas básicas para optimizar los tiempos de respuesta de nuestras aplicaciones, pero nunca está de más repasarlas.

La mayor parte de estas recomendaciones surgen del trabajo de Steve Souders, iniciado cuando era el Chief Performance en Yahoo!, antes de continuar esta labor desde Google, y compilado en dos libros que ya debería considerarse como obligatorios para cualquier desarrollador que tenga que tocar algo en la web:

Even Faster Web Sites

High Performace Web Sites (de 1997) y Even Faster Web Sites (de 2009)

La mayoría de estas reglas pueden verse en detalle en el sitio para desarrolladores de Yahoo, especialmente en la sección de Mejores Prácticas para acelerar un Sitio Web o su equivalente en Google, Mejores prácticas de rendimiento Web.

Dejo un resumen rápido de algunas recomendaciones, para que se den una idea antes de zambullirse en la lectura de todo ese material.

Minimizar peticiones HTTP

  • Combinar archivos es una manera de reducir peticiones, por ejemplo, unificando las hojas de estilo y scripts
  • Utilizar Sprites CSS para combinar muchas imagenes en una sola y descomponerla en la página

Utilizar redes de distribución de contenido (CDNs)

Esto no aplica a cualquier sitio, porque implica un costo, pero cada vez aparecen más alternativas económicas o embebidas directamente sobre alguna plataforma más amplia.

Agregar expiración o control de cache en la cabecera

Tanto en contenido estático como dinámico, manejando apropiadamente estos mecanismos podemos lograr que el browser descargue una única vez los recursos que no varían. Esto es particularmente efectivo en cosas como imágenes, hojas de estilo, scripts, etc, pero también se puede lograr mantener la mayor parte del HMTL utilizando mecanismos de fragmentación para separar el contenido que realmente varía.

Comprimir componentes con Gzip

Esta es una de las recomendaciones que es casi gratuita. La mayoría de los navegadores modernos soportan este tipo de compresión que es estándar, lo mismo que casi todos los servidores web. Sólo implica indicar que debe ser utilizada al hacer las peticiones.

Ubicar las hojas de estilo arriba de la página

Ubicar los estilos en la cabecera del HTML hace que la carga de la página se perciba más rápida porque permite que suceda progresivamente.

Ubicar los scripts al final de la página

La descarga de los scripts genera muchas veces un freno a la descarga en paralelo de otros elementos, porque supo que parte del código puede estar escribiendo parte del contenido de la página. Hay varias técnicas para evitar el problema y mejorar el rendimiento general.

Evitar expresiones CSS

Estas expresiones permiten asignar valores dinámicos a propiedades de los estilos, pero esta es una operación peligrosa y lenta, por lo que se la convirtió en obsoleta.

Los scripts y hojas de estilo deberían ser externos

Independizar estos recursos mejorar usualmente el rendimiento porque además de poder paralelizarse la descarga, estos son recursos ideales para permanecer mucho tiempo en la cache del navegador.

Reducir la cantidad de búsquedas en los DNS

Esto es algo en lo que hay que mantener un balance. Las búsquedas en los servidores de nombres son mantenidos en cache por los navegadores por varios minutos, porque son una operación relativamente costosa. De todas maneras, cierta distribución de recursos en diferentes dominios también ayuda a paralelizar las descargas, ya que los navegadores tienen un límite de cantidad de descargas en paralelo por cada dominio.

Minificar JavaScript y hojas de estilo

Esta práctica implica compactar en ambos casos la cantidad de caracteres en uso para todos los recursos internos como estilos, variables y nombres de funciones, al igual que reducir la cantidad de espacios opcionales e indentación. Esto hace que el resultado parezca críptico, pero puede resolverse en una etapa posterior al desarrollo, como parte del despliegue (utilizando JSMin y YUI Compressor, por ejemplo), de modo que dentro del ciclo de vida de un proyecto nadie tenga que leer las versiones minificadas.

Evitar redirecciones

Aunque este es un recurso útil en ciertos casos, su abuso genera demoras y una experiencia poco prolija, que es difícil de optimizar.

Remover scripts duplicados

Aunque parezca obvio, la cantidad de sitios que incluyen mas de una vez el mismo script en una página es enorme. En parte, si se trabaja fuertemente en la unificación de los scripts, las posibilidades de que esto suceda disminuyen inmediatamente.

Configurar ETags

A pesar de que los ETags son un mecanismo para evitar transferir recursos ya existentes, implementaciones divergentes de este estándar en distintos servidores terminan generando que algunos recursos se descarguen siempre, sin importar si ya están actualizados en el navegador. Es importante revisar la manera en que funcionan y estar seguro que lo hacen correctamente.

Hacer que las llamadas AJAX utilicen la cache

Aunque esta técnica de pedir datos de manera asincrónica sin tener que reenviar toda la página está pensada para minimizar el tráfico, es importante aplicar muchas de las recomendaciones anteriores a estos casos también. Esto implica hacer que las respuestas generalmente dinámicas de estos servicios utilicen los mismos mecanismos para evitar el reenvío de respuestas que ya llegaron antes al navegador y cuyo contenido no cambió.

 

¿Cómo controlar y validar estas reglas?

Aunque la lista pueda amedrentarnos en principio, ya hay varias herramientas disponibles para ayudarnos en este camino, como la clásica YSlow (un plugin de FireBug, que a su vez es un plugin para FireFox). Va como muestra una captura del análisis de YSlow en este blog (para que vean que todos cometemos pecados).

Analisis de YSlow

Google, por su parte, tiene también una extensión similar pero con algunas características particulares, llamada PageSpeed, producto de la mudanza de Souders. Notablemente esta extensión también es para FireBug, por lo que corre en FireFox, no en Chrome.

Finalmente, Google ha publicado también el módulo mod_pagespeed para Apache, que aplica muchas de las reglas automáticamente, al preprocesar scripts y hojas de estilo, unificando y minificándolas, optimizando imagenes, etc.

Es interesante ver que GoDaddy, el principal registrador de domininos y una de las principales empresas de hosting en el mundo, ha empezado a activar este módulo en todos sus servidores Apache, produciendo mejoras significativas en muchísimos de sus cliente de manera casi mágica.

 

viernes, 14 de enero de 2011

Video: ¿Existe la mejor forma de probar?

Agiles

El martes pasado se realizó la reunión mensual de Agiles @ Buenos Aires, organizada por la comunidad local Agiles.org. Para estar al tanto de estas actividades conviene suscribirse a la lista de correo Agiles Argentina.

La mecánica de estas reuniones es que tradicionalmente al cierre de cada una se proponen y votan los temas para la próxima, teniendo en cuenta temas que estaban pendientes en una especie de backlog informal.

Esta vez el tema central fue el testing desde un punto de vista ágil, iniciando con la presentación de Juan Gabardini titulada "¿Existe la mejor forma de probar?". En la sesión Juan recorre su experiencia personal como desarrollador volcado a tareas más ligadas a control de calidad (QA), recorriendo el espectro desde las pruebas manuales hasta las técnicas de automatización más sofisticadas, y reflexionando sobre el valor de cada variante y sus combinaciones.

La segunda mitad del evento fue una serie de preguntas, respuestas y debate a raíz de la presentación, que fue muy interesante pero es difícil de compartir en video.

Afortunadamente, si tenemos grabada la presentación de Juan, y para todos aquellos que tengan dudas o temas a debatir, creo que lo mejor puede ser plantearlos en la lista, donde tanto Juan como otros agilistas pueden aportar sus opiniones.

 

 

 

miércoles, 5 de enero de 2011

Probando aplicaciones web con Zombie.js

http://www.flickr.com/photos/tohoscope/5086711384/Probar aplicaciones web modernas, con mucho scripting del lado cliente, es cada vez más complejo. El hecho de que la interfaz de usuario cambie dependiendo de las interacciones sin necesidad de pasar por el servidor genera la necesidad de realizar pruebas sobre el lado cliente.

El problema de esto es que la mayor parte de las herramientas para efectuar este tipo de pruebas requiere de una instancia de un browser real, lo que genera una dependencia fuerte y sobre todo, implica que cada prueba tarde más porque un browser demora un montón de tiempo en cargar y dibujar los elementos y tiene en cuenta montones de cosas que en realidad no necesitamos en la mayoría de los escenarios para hacer pruebas automatizadas.

Zombie.js se llama así porque es un entorno de prueba headless (sin cabeza; en realidad sin browser), y es muy rápido, además de brindar un API muy cómoda para escribir las pruebas.

La plataforma hace uso nuevamente de las ventajas de Node.js (más detalles en un post anterior) para recrear el entorno de un browser, incluyendo el DOM y características de HTML5, pero sin la necesidad de dibujar realmente nada, lo que le permite alcanzar velocidades totalmente diferentes.

Para lograr este entorno, Zombie combina varias librerías abiertas como JSDOM para emular el DOM, HTML5 para parsing, Sizzle para los selectores CSS y AJAXSLT para el soporte a XPath. Y el proyecto a su vez, también está abierto a quien quiera meter mano, alojado en GitHub.

Veamos un brevísimo ejemplo de cómo instanciar el entorno de un browser, navegar a una página, identificarse y verificar que la operación sea exitosa al llegar a una siguiente página de bienvenida.

var zombie = require("zombie");
var assert = require("assert");


// Carga la página desde el localhost
zombie.visit("http://localhost:3000/", function (err, browser) {


  // Completa email y password y confirma el formulario
  browser.
    fill("email", "zombie@underworld.dead").
    fill("password", "eat-the-living").
    pressButton("Sign Me Up!", function(err, browser) {


      // Al procesar el form, ve si fue a la página correcta
      assert.equal(browser.text("title"), "Welcome To Brains Depot");
    })
});

Como se ve, el API es muy sencilla y natural, y como siempre en Node, no hay llamadas bloqueantes; todo lo que pasa se maneja con callbacks, lo que hace también que correr una batería importante de pruebas sea más rápido en total, facilitando la ejecución más frecuente, lo que siempre eleva la calidad del proceso de desarrollo.

 

jueves, 16 de diciembre de 2010

Video: Windmill trae una alternativa al testing web

Windmill

La mayoría del testing automatizado sobre aplicaciones web se hace hoy día utilizando Selenium, que se ganó su predominancia por haber sido el primer framework completo para este objetivo.

Sin embargo, quienes lo utilizan bastante empiezan a notar algunos problemas estructurales que no le restan valor, pero complican el pasar de cierto nivel de aseguramiento. Como siempre, una buena respuesta a lo límites de una herramienta suele ser utilizar otras complementarias, sacando provecho de la diversidad.

Windmill es otro framework open source,  para efectuar este tipo de pruebas que tiene algunas características prometedoras y está siendo cada vez más apreciado en la comunidad. El producto corre en Python pero sirve para probar cualquier tipo de interfaz web, soportando múltiples browsers (incluso, con algunos cuidados, el problemático IE6).

Algunas de sus características principales:

  • Múltiples browsers
  • Grabación, Edición y Ejecución de pruebas
  • Shell interactivo, basado en Python, que permite scripts para extender los casos
  • API de Proxy que permite interceptar y modificar el contexto de ejecución para contemplar situaciones posibles en distintos browsers y escenarios cliente
  • Las pruebas pueden escribirse también en Javascript, incluyendo las funciones de JSUnit
  • Controller API que permite ejecutar programáticamente cualquier tipo de acción interactiva como cliquear, escribir, esperar, arrastrar y soltar, hacer clic derecho, etc.

Pero como nada es mejor que ver algo en acción, aquí comparto un video demostrando rápidamente el framework en acción: