30.10.06

Combinando el modo grabar/reproducir con el modo API de código de Selenium

Saludos.

Selenium (http://www.openqa.org/) es una herramienta open-source estupenda para realizar pruebas de sistema / aceptación de aplicaciones web. Selenium incluye una herramienta que se integra con Firefox y que permite grabar todo lo que hagamos con Firefox, guardarlo en un archivo, y reproducirlo después. Además, Selenium también incluye la posibilidad de escribir nuestras pruebas directamente en Java, C#, Python y Ruby.

Para un proyecto real, estábamos muy interesados en utilizar Selenium y su herramienta para grabar / reproducir pruebas. Sin embargo, queríamos hacer dos cosas que no se pueden hacer con la filosofía de grabar / reproducir: la primera es añadir código adicional que compruebe el estado de la aplicación y el estado de la base de datos y la segunda ejecutar todas las pruebas grabadas automáticamente cada cierto tiempo.

Por suerte el código de una prueba cuando se graba es muy similar al código que habría que escribir en un lenguaje, por ejemplo en Java o CSharp. A continuación incluyo el código de una sencilla prueba

Código 1. Prueba grabada con Firefox.


class NewTest
def test_foo
open "/links_jsp/Default.jsp"
assertTitle "Links"
clickAndWait "//a[contains(@href, 'LinkNew.jsp')]"
assertTitle "Links"
type "name", "Prueba"
type "link_url", "Prueba"
type "description", "URL de prueba"
clickAndWait "//input[@value='Insert']"
assertTitle "Links"
end
end


Código 2. Prueba escrita en Java


import com.thoughtworks.selenium.*;
import junit.framework.*;


public class Selenium_InsertarEnlace extends TestCase {

private Selenium sel;

public void setUp() {
sel = new DefaultSelenium("localhost",
4444, "*firefox", "http:/localhost:8080");
sel.start();
}

public void testInsertarEnlace() {
sel.open("/links_jsp/Default.jsp");
assertEquals("Links", sel.getTitle());
sel.click("//a[contains(@href, 'LinkNew.jsp')]");
sel.waitForPageToLoad("5000");
sel.type("name", "Prueba");
sel.type("link_url", "Prueba");
sel.type("description", "URL de prueba");
sel.click("//input[@value='Insert']");
sel.waitForPageToLoad("5000");
assertEquals("Links", sel.getTitle());
}

public void tearDown() {
sel.stop();
}

public static void main(String[] args) {
junit.textui.TestRunner.run(new TestSuite(Selenium_InsertarEnlace.class));
}
}


Código 3. Prueba escrita en CSharp

using Selenium;
using NUnit.Framework;
namespace MyTests {
[TestFixture]
public class Selenium_InsertarEnlace {
private ISelenium sel;

[SetUp]
public void SetUp() {
sel = new DefaultSelenium("localhost",
4444, "*firefox", "http:/localhost:8080");
sel.Start();
}

[Test]
public void testGoogle() {
sel.Open("/links_jsp/Default.jsp");
Assert.AreEqual("Links", sel.getTitle());
sel.Click("//a[contains(@href, 'LinkNew.jsp')]");
sel.WaitForPageToLoad("5000");
sel.Type("name", "Prueba");
sel.Type("link_url", "Prueba");
sel.Type("description", "URL de prueba");
sel.Click("//input[@value='Insert']");
sel.WaitForPageToLoad("5000");
Assert.AreEqual("Links", sel.getTitle());
}

[TearDown]
public void TearDown() {
sel.stop();
}
}
}



Para ejecutar la prueba en Java, es necesario tener en ejecución el servidor de Selenium ("java -jar selenium-server.jar") y tener en el PATH la ruta a Firefox. Al ejecutar la prueba en Java (necesitamos "selenium-java-client-driver.jar") se abrirá una nueva instancia del Firefox y, en la salida estándar veremos el resultado de la prueba. La prueba en CSharp no la hemos ejecutado, pero debería ser igual de sencillo.

Ahora es posible añadir a la prueba todas las comprobaciones adicionales que queramos como, por ejemplo, conectar con la BBDD para asegurarnos que el enlace está ahí.

Estamos escribiendo un sencillo script para traducir automáticamente el código de una prueba capturada a código Java. Si alguien está interesado no tiene más que escribirme.

25.10.06

Aplicaciones autoadministradas y autoreparadas

Después de asistir a la conferencia de un gurú (o eso dijeron) de la arquitectura de software en un congreso, me llevo la idea de que el desarrollo de aplicaciones que sean capaces de administrase ellas solitas (y de paso repararse) es un buen nicho de mercado.

Esto no es, ni mucho menos, ciencia-ficción. Si no me equivoco la plataforma Java ya incorpora desde hace tiempo interfaces de monitorización de componentes bajo el nombre de JMX.

Para poder hacer esto, dado que la tecnología existe, lo que hay que hacer es plantearlo desde el comienzo del desarrollo de la aplicación e incluir en nuestra aplicación, módulos que monitoricen el funcionamiento de la misma y que tengan la capacidad de tomar las medidas correctivas necesarias. Esto puede venderse muy bien, ya que, como nos comentó el gurú, por cada dólar gastado en adquirir una aplicación (esto incluye el desarrollo a medida), se gastan nueve dólares en su administración y mantenimiento (en euros será menos, seguro). Si podemos desarrollar aplicaciones autoadministradas, podemos reducir el gasto durante toda la vida útil de la aplicación de nuestros clientes 9 veces, lo cuál es bastante interesante.

Además una aplicación que sea capaz de arreglarse a sí misma, es una aplicación que no tiene por qué detenerse nunca, lo cuál es muy beneficioso en ciertos nichos de mercado.

19.10.06

Presentaciones "De casos de uso a casos de prueba" en mi web

Saludos.

He puesto en mi web el 95% de las presentaciones que voy a usar en el seminario "De casos de uso a casos de prueba" que impartiré el martes 24 en el evento SoloRequisitos. La dirección es:

http://www.lsi.us.es/~javierj/cursos.htm

Después del evento publicaré el 100% de las transparencias, aunque el 5% que falta son las menos importantes.

Feliz otoño

18.10.06

Eclipse. Caballo ganador en la investigación

Saludos.

A menudo nos encontramos comparativas entre Eclipse y NetBeans y muchas veces nos da la impresión (al menos a mí) de que ambas plataformas tienen una lucha feroz por imponerse en el mundo de la empresa.
sin embargo en el mundo de la investigación y las universidades no es así. Por lo que he podido ver en un reciente congreso, todo el mundo usa Eclipse y desarrolla sus ideas a partir de Eclipse. En ese sentido, el EMF es una herramienta de uso casi inevitable. Netbeans no aparece por ningún sitio ni se le espera.

¡Dios mío, yo uso Netbeans!. ¿De dónde me puedo descargar Eclipse?.

16.10.06

Evitando el lado oscuro de las pruebas (y II)

Como ya comentamos hace tiempo en este blog, las pruebas de código tipo JUnit tienen un lado oscuro. Si el código cambia, las pruebas pueden quedar inservibles, lo cuál supone un desperdicio de tiempo y recursos.

La solución que propuse fue la de intentar automatizar lo máximo posible la generación de pruebas. Así, si el código cambiaba, simpleente se volvía a ejecutar el programa que generaba un nuevo conjunto de pruebas.

Otra posible solución que se ha comentado en el taller de pruebas es la verificacón estática del código. Es decir, revisar el código para buscar errores antes de ejecutarlo. Según comentaron, las revisiones estáticas de código pueden resolver cerca de un 80% de los errores básicos. Un artículo muy bueno al respecto puede encontrase en (http://in2test.lsi.uniovi.es/pris2006/).

Feliz otoño.