A menudo necesitamos realizar operaciones cuando ocurren eventos. En este tipo de situaciones existen dos soluciones: inyectar el objeto que tiene que recibir los eventos en el que los provoca o implementar el patrón Observer (“Observador”, pero es raro que alguien traduzca los nombres de los patrones).

También es posible que un objeto genere eventos pero sean varios los consumidores de éstos. En swing, gtk,… ocurre constantemente, utilizando los conocidos listeners. Pero… ¿Qué es un listener realmente? No es más que una implementación del patrón Observer.

Veremos cómo utilizar este utilísimo patrón en Java y en Python.

Una vez tenemos los conocimientos básicos de Tornado, lo lógico es seguir añadiendo características del framework.

En este caso voy a añadir una de las características más importantes: el entorno de pruebas. En mi opinión, es siempre lo primero que se debería enseñar, mucho antes de otras cosas como el sistema de location (idiomas, etc.), acceso a servicios de terceros (google, facebook, twitter, oauth, …) y otras cosas molonas.

Partiremos de los conocimientos anteriores y pondremos un ejemplo sencillo de uso de esta herramienta.

Se tratará de pruebas de integración. No se utilizará un Browser, y podremos mockear lo que nos haga falta (aunque en este artículo no se utilizarán mocks).

En esta ocasión trataré de ver cómo utilizar un framework de red, como es el caso de python-tornado.

Crearemos un site pequeño y básico, lo justo como para tener una idea de sus posibilidades.

En cuanto al uso, yo últimamente lo utilizo para todo: desde pequeñas aplicaciones web hasta herramientas de soporte en el escritorio, donde necesito un servidor.

En los artículos anteriores, ”Selenium y QA Automation” y ”Selenium y QA Automation: Tests” hemos visto cómo utilizar Selenium/Webdriver.

En este caso vamos a ver cómo organizar estos tests. Realmente no es necesario el conocimiento previo de Selenium, ya que puede utilizarse algún otro framework. Sin embargo, sí que resulta interesante ya que lo usaremos para los ejemplos.

Aunque los PageObjects se idearon para pruebas en la Web (de hecho, creo que son una idea de Selenium), este artículo está escrito pensando que los PageObjects pueden usarse tanto en aplicaciones de escritorio como web, por lo que veréis “pantalla” o “página” indistintamente.

Este artículo ya lo escribí en Crysol, pero lo replico aquí porque he estado a punto de volver a currármelo porque no lo encontraba XD

Estaba harto de encontrarme ficheros ~, ## y .semantic por todas partes, y puede llegar a ser muy aburrido borrarlos periódicamente. ¡Tiene que haber alguna manera de optimizar esto! Y, efectivamente…

En mi anterior post sobre Selenium y QA Automation comenzamos a ver cómo utilizar Selenium/Webdriver para la automatización de tareas web. En esta ocasión lo adaptaremos para su uso más habitual: la creación de pruebas de aceptación.

Mediante ejemplos en Python adaptaremos nuestro ejercicio anterior para ejecutarlo como tests. Así mismo, refactorizaremos para obtener un entorno de pruebas sencillo, extensible y fácil de utilizar.

Tras este artículo, no debería ser difícil utilizar un sistema de integración contínua para la automatización de pruebas de aceptación.

En el mundo de la automatización de pruebas, Selenium arrasa. Existen otras alternativas, pero lo cierto es que todo el mundo utiliza Selenium.

Hay distintas formas de utilizarlo, y aquí veremos algunas de ellas. He elegido Python porque es mi lenguaje favorito y Java porque es el lenguaje en el que está hecho Selenium.

After writting the article Why Java rocks, I have no other option than writting why Python rocks.

Before starting, I might advise you that Python is my favourite language. And this is like search your best friends defects.