Los pre requisitos según el tutorial  son instalar la Java 7 (evidentemente) e instalar Eclipse Indigo 3.7.1, sin embargo como bien indican los amigos de JavaHispano también se puede realizar con cualquier otro IDE.

El tutorial es muy bien ya que es corto y sencillo, y todo los fragmentos de código vienen con su correspondiente explicación.

Salu2. Héctor.

Para analizar si tu web puede ser más rápida todavía de forma muy sencilla y practica puedes utilizar Pingdom Tools. Pingdom Tools es una web gratuita que analiza la velocidad de carga de tu sitio web y te propone recomendaciones para hacerla más rápida. Analiza que elementos son rapidas, lentos, que buenas practicas no se están siguiendo y muestra los resultados de manera que pueden ser útiles tanto para webmaster expertos como novatos.

Las principales características son:

• Examina todas las partes de la web: Tamaños de archivos, tiempos de carga, y otros detalles de cada uno de los elementos que forman la web (HTML, JavaScript, css, imagenes, …). Una vez analizados muestra un listado que se puede ordenar por tiempos para identificar los cuellos de botella.
• Descripción general del rendimiento: Automáticamente analiza una gran cantidad de estadísticas para obtener el resultado de la prueba.
• Grado de rendimiento y consejos: Muestra como se adapta nuestra web a las buenas practicas marcadas por Google Page Speed o Yahoo YSlow, además muestra algunos consejos sobre como mejorar la velocidad de carga.
• Histórico de pruebas: Almacenan cada una de las pruebas que se realicen y muestras la diferencias entre cada una de ellas. Muy útil para analizar si los cambios están surtiendo el efecto deseado.
• Prueba en varias ubicaciones: Muestra las diferencias de cada de la web en Europa, Estados Unidos, …
• Compartir los resultados: Permite descargarse los resultados para compartirlos o analizarlos con detenimiento.

La siguiente imagen muestra el análisis realizado sobre mi web:

Lo primero que muestra es un resultado global en el que dice que nota sobre 1oo tiene tu web, en mi caso casi notable 69/100, además de las request realizadas (80), el tiempo de carga (1,47sg) y el tamaño (677,4 kb). Además muestra como es de rápida tu web respecto al resto de sitios analizados, en mi caso es más rápida que el 81% de web analizadas.

Un poco más abajo, muestra un listado que se puede modificar porque tiene varias pestañas. En la pestaña Waterfall muestra que elementos a cargado, su tamaño y tiempo de carga. En mi caso me penaliza el banner superior que tengo de la Fundación Vicente Ferrer ya que es una imagen de 50kb que comparado con el resto de elementos resulta un poco grande. No obstante, no pienso quitarlo ya que si consigo que uno de vosotros apadrine un niño estaría encantado.

Espero que os haga gustado. Si conoceis más herramientas de este tipo además de Pingdom Tools, Google Page Speed o Yahoo! YSlow estaría encantado de probarlas.

Salu2. Héctor.

Parece ser que la comunidad Jenkins esta promoviendo una serie de estadísticas y datos que indicarían que Hudson esta perdiendo fuerza respecto a Jenkins . Según sus datos Jenkins ya supera tanto en reconocimiento de marca como en adopción, indicando que el 85% de las actualizaciones van hacia Jenkins.

Según indican, desde que Jenkins se paso GitHub y Oracle cedio Hudson a Eclipse (Hudson se encuentra en Incubation)  el ratio de descargas es de 60 a 1 a favor de Jenkins.

Es más que evidente el tremendo auge que ha tenido Jenkins y el gran apoyo que esta recibiendo por su comunidad los cuales han dado la espalda a Hudson. Otra de los datos que aportan es el “Ticket Activity” como indicador de uso que es muy favorable a Jenkins como se puede observar en la siguiente gráfica.

En la siguiente imagen se puede observar en color rojo la actividad de Jenkins en el mundo (podrían haber puesto también la de Hudson por comparar) y la gran difusión obtenida en todo el globo terráqueo.

Esta muy bien esta euforia por parte de Jenkins, pero me pregunto, ¿todo esto es  suficientes para dar por vencido a Hudson? La división Jenkins/Hudson es muy reciente (6 meses aprox.) , y teniendo a Oracle y Eclipse detrás, creo que es demasiado pronto para dar la victoria a Jenkins.

Qué opináis ¿quien lo tiene más complicado Hudson o Rubalcaba?

Tenéis toda la info en este documento: Jenkins: The Safe and Sensible Choice for Your Continuous Integration (CI) Investment

Salu2. Héctor.

• Se acabaron los problemas con los class loaders, dada su vinculación (binding) estática con la implementación subyacente (con JCL es dinámica en tiempo de ejecución).
• Trazado con parámetros mucho más sencillo y eficiente.
• Independencia, dado que puedes usar múltiples vinculaciones con sólo añadir otro “.jar” (p.e.: desde “slf4j-simple-x.x.x.jar“, para pequeñas aplicaciones que usen System.err hasta “slf4j-log4j12-x.x.x.jar“, para servir de puente a log4j.)

Si queréis conocer más sobre ello, os invito a que echéis un vistazo al articulo de Balteus donde enumera algunas de las mejoras que ofrece logback.

En este caso yo os presento a SLF4J Migrator que es es una herramienta Java para migrar tus fuentes Java de Jakarta Commons Logging(JCL) a SLF4J. También puede migrar de la API log4j a SLF4J, o de java.util.logging a SLF4J.

Para poder utilizarlo, lo primero que debemos hacer es descargarnos la distribución de slf4j que incluye el slf4j-migrator-version.jar (en mi caso 1.6.4). Una vez lo tenemos ejecutamos lo siguiente:

java -jar slf4j-migrator-1.6.4.jar

Si esta todo correcto, nos tiene que aparecer la siguiente pantalla:

Lo primero que llama la atención es el WARNING en color rojo y que dice: Cuidado, si me utilizas voy a cambiar tus fuentes y no voy hacer ningún tipo de copia de seguridad, ¿eres consciente? Vamos que no se hace responsable de la que te puede liar (por eso lo llamo especial para impacientes).

A continuación seleccionamos la migración, en mi caso de log4j a sfl4j y marcamos el check diciendo  que sabemos lo que estamos haciendo y …

En este caso solamente tenía una clase Java. Como veréis a continuación, esta herramienta hace las tareas más básicas, como modificar los imports  y la declaración del logger. Esta era mi clase que utiliza log4j antes de la migración:

package es.fuenteperez;

import org.apache.log4j.Logger;

public class Main {

	private static Logger log = Logger.getLogger(Main.class);

	public static void main(String[] args) {
			try {
				logger.info("Hola Mundo INFO!!");

				if(logger.isDebugEnabled()){
					logger.debug("Hola mundo DEBUG!");
				}

			} catch (Exception e) {
				logger.error("Se ha producido un error: ", e);
			}
		}

	}
}

y esta es la nueva clase que utiliza sfl4j

package es.fuenteperez;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Main {

	private static Logger logger = LoggerFactory.getLogger(Main.class);

	public static void main(String[] args) {
		try {
			logger.info("Hola Mundo INFO!!");

			if (logger.isDebugEnabled()) {
				logger.debug("Hola mundo DEBUG!");
			}

		} catch (Exception e) {
			logger.error("Se ha producido un error: ", e);
		}
	}
}

Limitaciones Generales

No todo iba a ser maravilloso, a continuación enumero algunas limitaciones generales en los 3 tipos de migraciones.

• Solo modifica ficheros Java, por tanto tendras que modificar todos tus scripts (Ant/Maven/Ivy) manualmente.
• Únicamente esta soportados los mensajes de tipo String.  Por ejemplo:

logger.debug(new Object()); –> logger.debug(new Object().toString());

• El nivel FATAL no está soportado. ¿Quien utiliza FATAL?
• Si un método declara varios logger la transformación no funciona correctamente ya que únicamente modifica el primero, p.e:

public void someMethod(Log l1, Log l2) {
   ...
  }

lo convierte a

  public void someMethod(Log l1, Logger l2) {
   ...
  }

Limitaciones cuando migramos desde log4j

• Las declaraciones NDC (Nested Diagnostic Context) no estan soportadas y se quedan como están y deben ser migradas manualmente a MDC (Mapped Diagnostic Context). Un NDC es un instrumento para distinguir salidas de log intercaladas que provienen de distintas fuentes. Las salidas de log suelen ser intercaladas cuando un servidor maneja varios clientes al mismo tiempo. El MDC es lo mismo que el NDC solo que usando un Map como implementación. Más información sobre el tema.
• Llamadas a PropertyConfigurator o DomConfigurator no se pueden migar porque no estan soportadas por sfl4j.

Limitaciones cuando migramos desde JUL

• No se modifican las llamadas a los métodos finest(), finer() o finest() de java.logging.Logger. Esto es debido a que estas llamadas se pueden corresponder con los métodos trace() o debug(), por tanto será tarea del desarrollador decidir porque método deseas sustituirlos.
• Todas las cadenas de caracteres que correspondas con “.severe(“ serán sustituidas por “.error(“, así como todas las cadenas “.warning(“ serán sustituidas por “.warn(” sin realizar ningún análisis contextual. Dado que la operación de comprobación/sustitución no es contextual, si  nuestro código contiene métodos llamados “severe” o “warning”  (p.e. servicioEjemplo.warning(String cadena) ) se generaran errores de compilación. Yo  nunca he creado en alguna de mis clases un método con  este nombre pero si alguno de vosotros lo hace que  sepáis que con la migración va a fallar.
• Las llamadas a los siguientes métodos de la clase java.util.logging.Logger deben migrarse manualmente: log, logp, logrb, entering y exiting.

Ya veis que existen una serie de limitaciones que pueden echaros un poco para atrás a la hora de hacer la migración con SFL4J Migrator, sin embargo creo que son casos muy concreto, y en mi caso probablemente el 95% de mis proyectos se migrarían sin problemas, eso si no os olvidéis de quitar los antiguos jars y añadir los nuevos que eso tampoco lo hace la herramienta.

Salu2. Héctor.

Alexa es el sitio web por excelencia para obtener información acerca de la cantidad de  visitas que recibe un  sitio web determinado. Alexa recoge información de los usuarios que tienen instalado Alexa Toolbar, lo cual le permite generar estadísticas acerca de la cantidad de visitas y de los enlaces relacionados. Alexa es una empresa subsidiaria de Amazon.

Traffic Estimate lleva funcionando desde 2004. Da información sobre visitas, enlaces, etc pero lo que más me llama la atención es que hacen especial hincapié en el tema de la competencia, indicando cuantos competidores utilizan palabras clave tuyas e incluso de dan el nombre (URL) de los que cree que son tus competidores.

Statbrain utiliza varias fuentes para realizar una aproximación bastante acertada del número de visitas que tiene una web. Este servicio online toma como referencia desde el ranking de Alexa hasta los enlaces de Google, Altavista o Yahoo para realizar su propia estimación.

En este caso, My Domain Stats explica que su estimación de tráfico no tiene acceso directo a los datos de DNS o registros de acceso. Se basa en un modelo estadístico que trata de extrapolar el tráfico existente en un dominio, basado únicamente en los indicadores presentados.

Lo más curioso de esta web es que se atreve a dar un valor aproximado de la web, además de que te permite introducir el número de visitas reales  si las conoces.

En mi caso My Domain Stats dice que tengo 202 visitas únicas en el último mes, cuando realmente he tenido 1.052 según Google Analytics y que su precio es de 65$ (que es más de lo que yo pensaba )

Mi opinión es que estas web están bien para hacerte una leve idea de si una página tiene un número superior de visitas que la tuya o pasar un rato entretenido viendo estadísticas pero que no son ninguna maravilla.

A mí la que más me gusta es Alexa aunque me de un Ranking bastante patético

Salu2. Héctor.

Para situarnos, existen una serie de paginas como PayPerPost, ReviewMe, Zync y PagoPorPost que se encarga de poner en contacto blogs con anunciantes. Los anunciantes pagan para que blogs hablen de sus productos, estos son los post patrocinados. Evidentemente estos sistemas se llevan parte del dinero del anunciante.

Dentro de estos sistemas existen diferencias como los que permiten hablar bien o mal del producto o los que solo permiten hablar bien; sistemas que obligan a indicar que el post es publicidad y los que promueven el disimulo.  Entre los primero se encuentran ReviewMe y Zinc y en los segundos PayPerPost y PagoPorPost.

Entrar a formar parte de estos sistemas no es complicado siempre que tenga un blog con muchas visitas, un buen PageRank, índices de Alexa y Technorati aceptables, gran frecuencia de actualización del blog, … vamos que no dejan entrar a cualquiera personaje como el que escribe.

Además parece que participar en estos sistemas tampoco sale gratis. Por ejemplo WordPress dice lo siguiente al respecto:

“WordPress está tratando de crear un servicio y una marca de calidad, y piensan que PayPerPost no es más que otro intento de jugar con los motores de búsqueda. Así que si usted quiere usar esa fórmula, búsquese otro sitio porque no podrá hacerlo en WordPress.com”.

Y además equipara PayPerPost con spam. A Google tampoco es que le hagan mucha gracia estos sistemas (tal vez porque no se les ha ocurrido a ellos) y piensan que es un intento de manipular el algoritmo de relevancia y conseguir enlaces de manera artificial y añade:

“Por ello, desde Google ya han tomado cartas en el asunto, y el propio Matt Cutts (responsable de la calidad del buscador) asegura en este comentario en un blogque pretenden “llevar a cabo un buen trabajo detectando venta de enlaces”. “Los enlaces pagados que afectan a los buscadores (tanto enlaces de texto como posts patrocinados) pueden suponer una pérdida de confianza por parte de Google”, subraya”.

Por lo que parece Google penaliza a los blog que utilizan estos sistemas,  aunque existen algunas formas de intentar engañar a Google como ref=”nofollow” para que el robot de Google no te siga el link.

Existen multitud de opiniones en la web, desde los que están a favor y creen  que Google quiere todo el mercado para ellos, los que piensan como Matt Cutts o los están a favor siempre que  se indique, que es un enlace patrocinado y la opinión es sincera y objetiva.

Yo soy de la opinión de estos últimos, ya que la persona esta advertida de que me han pagado por evaluar el “producto” y por tanto puede ser una opinión sesgada.

Imaginemos el siguiente escenario: blog de atletismo escribe un artículo  sobre unas zapatillas que le gustan mucho al blogger y este es usuario de Adsense. Mi pregunta es: ¿Google Adsense mostrara primero la mejor oferta o mostrara la del anunciante que más le interese?

Vosotros que pensáis. ¿Alguien nos pueden contar su experiencia con alguno de estos sistemas?

Salu2. Héctor.

Yo tengo Adsense desde los inicios  del blog y la verdad es no he ganado todavía ni un céntimo de €, pero me parece gracioso ver como me dan 0,10€ por un click y cuantas impresiones tengo al día.

La verdad es que las tablas que salen en Adsense son un poco rollo, y se echa en falta alguna gráfica que haba más ameno el entorno como en Google Analytics. Puse en el Google Adsense graficas y me encontré Visual Adsense.

Visual Adsense es una página web que analiza tus informes de Google Adsense, para mostrarte gráficas dinámicas de datos útiles y comprensibles sobre los ingresos que obtienes con Adsense.

Yo la verdad es que si le he pasado unos cuantos informes, lo que sucede  que las graficas que salen son tan cutres (por las pocas visitas e ingresos)  que  las imágenes  que os pongo aquí son de otras páginas. Para los desconfiados o que tengan datos más interesantes que los míos, Visual Adsense informa de que NO GUARDA los informes una vez usados para la generación de gráficas.

Además no es necesario darse de alta y los datos que se almacenan en el fichero CSV no contiene información de tu cuenta Adsense. En la siguiente imagen se muestra la tabla CSV obtenida de mi sitio web en el mes de Octubre:

Espero que vuestras gráficas de impresiones y ganancias muestren resultados mejores que los míos.

Salu2. Héctor

En este articulo os voy a proponer dos opciones para obtener los parámetros que viajan en una URL. En Flex existen varias formas de pasar parámetros a una aplicación mediante la URL, ya sea mediante variables flashVars o añadiendo los parámetros como si fuese un get (p.e for example, MyApp.swf?value1=x&value2=y).

En este post, lo que quiero mostrar son dos soluciones para cuando nuestro swf este embebido dentro del wrapper HTML.

La primera solución y la que yo utilizo, es la propuesta por Abdul Qabiz. Es una clase ActionScript la cual echa mano de la clase ExternalInterface para obtener la URL mediante JavaScript, una vez recuperada realiza un parseo para obtener los pares variable-valor. Esta es la parte central del código se basa en la clase ExternalInterface para obtener los parametros mediante JS:

private function readQueryString():void
{
	_params = {};
	try
	{
		_all =  ExternalInterface.call("window.location.href.toString");
		_queryString = ExternalInterface.call("window.location.search.substring", 1);
		if(_queryString)
		{
			var params:Array = _queryString.split('&');
			var _length:uint = params.length;

			for (var i:uint=0,index:int=-1; i < _length; i++)
			{
				var kvPair:String = params[i];
				if((index = kvPair.indexOf("=")) > 0)
				{
					var key:String = kvPair.substring(0,index);
					var value:String = kvPair.substring(index+1);
					_params[key] = value;
				}
			}
		}
	}catch(e:Error) { trace("Some error occured. ExternalInterface doesn't work in Standalone player."); }
}

La segunda solución es la ofrecida por Adobe. A mi personalmente no me gusta demasiado, ya que para poder utilizar esta solución hay que introducir el caracter # antes de los parámetros de la URL, por ejemplo:

http://www.mydomain.com/MyApp.html#firstName=Nick&lastName=Danger

Esto es debido a que utiliza la clase BrowserManager (que nos permite realizar diferentes tareas con la URL) junto con la clase URLUtil que nos permite parsea la URL y pasarlo a un Object. En el siguiente código se puede ver más claramente.

private function init(e:Event):void {
    bm = BrowserManager.getInstance();
    bm.init("", "Welcome!");

   /* The following code will parse a URL that passes firstName and lastName as
       query string parameters after the "#" sign; for example:
   http://www.mydomain.com/MyApp.html#firstName=Nick&lastName=Danger */
   var o:Object = URLUtil.stringToObject(bm.fragment, "&");
   fName = o.firstName;
   lName = o.lastName;
}

Supongo que conoceréis más maneras de acceder a los parámetros de la URL desde Flex, aquí podéis descargar esta dos soluciones en un proyecto Eclipse por si os apetece probarlo.

Salu2. Héctor.

Antes de intentar instalar Android en vuestro PC, podéis echarle un vistazo a este post donde muestro la evolución de Android.

En este articulo voy a describir los pasos para crear una maquina virtual con el sistema operativo Android OS. Para crear la maquina virtual vamos a utilizar Oracle VirtualBox, pero podriamos utilizar otros software como VMWare, QEMU, … más  info sobre Maquinas Virtuales.

Para el sistema operativo vamos a utilizar Live Android. Live Android es un proyecto que un LiveCD para hacer funcionar Android en plataformas x86. El liveCD es similar a otras distribuciones Live CD Linux como Knoppix, la cual es suficiente con introducir el CD en el arranque de nuestro equipo e indicar que nuestro equipo tire de la unidad donde tengamos el CD/DVD. De esta forma podemos probar un sistema operativo sin alterar o modificar el SO y los archivos instalados en nuestro PC.  Indicar que Live Android no es 100% compatible con Android, sin embargo nos servirá para ver las cosas más importantes.

Además del LiveCD, tambien podemos instalarlo dentro de una maquina virtual. Para ello vamos a la zona de descargas del proyecto.  Descargamos la iso que se encuentra en dos archivos liveandroidv.0.3.iso.001 y liveandroidv.0.3.iso.002.

También existe la posibilidad de descargarse el torrent. Para crear el ISO podemos hacer con HJSplit en Windows o en el caso de Linux mediante la sentencia: cat liveandroidv0.3.iso.001 liveandroidv0.3.iso.002 > liveandroidv0.3.iso.

Una vez tenemos la ISO completa ya podemos comenzar a crear la maquina virtual. Para ello ejecutamos VirtualBox y pulsamos sobre Nueva Maquina Virtual.

• Nos aparece un wizart que nos solicita el nombre que le vamos a dar a la maquina virtual, el sistema operativo y la versión. En nuestro caso introducimos:

Nombre: AndroidOS

Sistema Operativo: Linux

Versión: Linux 2.6

• En el siguiente paso, nos van a solicitar el tamaño de la RAM de nuestra maquina virtual. Dejamos los 256 MB por defecto, pero podríamos establecer 128 MB sin ningún problema.

• El siguiente paso es crear el disco duro de nuestra maquina virtual. Para esto, VirtualBox no solicita una serie de datos. En nuestro caso vamos a crear un nuevo disco duro virtual, con un tamaño fijo de 512 MB. Podeis verlo en las imágenes.

• Después de realizar los pasos anteriores, nos debe mostrar la configuración del nuevo disco duro creado en una pantalla como la que se muestra en la siguiente imagen:

• Pulsamos el botón Terminar, y nos aparece una pantalla como el resumen de la maquina virtual que hemos creado.

• Hasta aquí ya tenemos configurada nuestra maquina virtual.

• Ahora debemos configurar el dispositivo para booterla. Para ello seleccionamos la maquina virtual que hemos creado y pulsamos sobre Iniciar.  Nos aparece la siguiente pantalla:

• En este punto, en el campo Fuente de medios debemos ir hasta la ruta donde hemos dejado la ISO liveandroidv0.3.iso y establecerla como medio de instalación. Pulsamos finalizar y arranca nuestra maquina virtual con Android. Nos aparecerá la siguiente pantalla para establecer la resolución:

• Seleccionamos la resolución que más nos guste 800*600 o 1024*768 y continua el arranque de la maquina virtual. Cuando se haya cargado por completo Android nos debe mostrar la siguiente imagen:

Ahora ya podéis cacharrear con Android sin necesidad de disponer de un Smartphone o una Tablet con Android.

Salu2. Héctor.

JUnit es un conjunto de clases que permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si  el funcionamiento de cada uno de los métodos de la clase se comporta como se espera.

Es decir, en función de algún valor de entrada se evalúa el valor de retorno esperado, si la clase cumple la especificación, entonces JUnit devolverá que el método de la clase pasó exitosamente la preuba. En caso de que el valor esperado sea diferente al retornado por el método durante la ejecución, Juni devolverá un fallo en el método correspondiente.

JUnit es tambien un medio para controlar las prueba de regresión, necesarias cuando una parte del código ha sido modificado y se desea ver que el nuevo código cumple los requisitos anteriores y que no se ha alterado su funcionalidad después de la nueva modificación.

Este framework se encuentra en el momento de escribir el post en la versión 4.5, con algunas mejoras:

• Incluye soporte para anotaciones (Java 5 Annotations).
• Permite timeouts en  los test.
• Configurar excepciones esperadas.
• Ordenación, priorización, categorización y filtrado de tests.
• Más tipos de aserciones (ej: assertEquals(Object[], Object[]).
• Se elimina la distinción entre errores (errors) y fallos (failures).
• …

A continuación vamos a ver un ejemplo de utilización de JUnit. La sobre la cual vamos  a realizar las pruebas se llama ArrayWrapper, consiste en una simple implementación de un wrapper sobre int array[], el cual tendra una serie de métodos. El código es el siguiente:

package es.fuenteperez.junit.base;
public class ArrayWrapper {
	int arr[];
	//Constructor
	public ArrayWrapper(int par[]){
		this.arr = par;
	}
	public int size(){
		return this.arr.length;
	}

	public String toString(){
		StringBuffer str = new StringBuffer();
		int i = 0;
		str.append("[");
		for (i = 0; i < this.arr.length - 1; i++) {
			str.append(arr[i] + ",");
		}
		str.append(arr[i] + "]");
		return str.toString();
	}
	public void setElementAt(int elemento, int indice){
		arr[indice] = elemento;
	}
	public int[] getArray(){
		return this.arr;
	}
}

Tiene una serie de metodos (constructor, size, toString, setElementAt y getArray).

Para poder realizar la prueba sobre una clase Java con JUnit, debemos seguir los siguientes pasos:

1. Descargar una versión de JUnit, y añadir la librería junit-version.jar al proyecto sobre el cual vamos a realizar las pruebas.
2. Crear la clase que  contrendrá las pruebas. En nuestro caso la hemos llamado TestArrayWrapper, por convenio el nombre  de la clase comienza por Test seguido del nombre de la clase sobre la cual realizamos las pruebas.
3. Importar el paquete junit.framework.TestCase.

   import junit.framework.TestCase;

4. Extender nuestra clase de prueba de TestCase.

   public class TestArrayWrapper extends TestCase{

5. Crear un método tipo void por cada prueba que se quiera  realizar. El nombre del método que va a probarse, debe empezar por el prefijo test.

   public void testSize(){
   }
   public void testToString(){
   }
   public void testSetElementAt(){
   }
   

6. Los casos de prueba se consideran exitosos o fallidos dependiendo de una  sentencia que se incluye en los casos de prueba y que es de tipo assert.

Siguiendo los pasos anteriores creamos nuestra clase Test. El código generado es el siguiente:

package es.fuenteperez.junit.test;
import es.fuenteperez.junit.base.ArrayWrapper;
import junit.framework.TestCase;
public class TestArrayWrapper extends TestCase{
	private int arr[];
	private ArrayWrapper arrayWrapper;
	private int TAMANO = 5;
	protected void setUp() throws Exception {
		super.setUp();
		arr = new int[TAMANO];
		for (int i = 0; i < arr.length; i++) {
			arr[i] = i;
		}
		arrayWrapper = new ArrayWrapper(arr);
	}
	protected void tearDown() throws Exception {
		super.tearDown();
             arrayWrapper = null;
	}
	public void testSize(){
	          assertEquals(TAMANO, arrayWrapper.size());
	}
	public void testToString(){
		arrayWrapper.getArray();
		assertEquals("[0,1,2,3,4]", arrayWrapper.toString());
	}
	public void testSetElementAt(){
		arrayWrapper.setElementAt(99, 2);
		int ret[] = arrayWrapper.getArray();
		assertEquals(99, ret[2]);
	}
}

Podemos observar dos métodos de los  cuales no habiamos hablado anteriormente, setUp() y tearDown(), son dos métodos que nos proporciona JUnit.

El método setUp() se ejecutara justo antes de la ejecución de cada uno de los metodos test. El método tearDown() se ejecuta justo después de la ejecución de cada uno de los test.

Por tanto podemos utilizar estos métodos para inicializar recursos, variables de clase o instanciar un atributo, basicamente se utiliza cuando la inicialización de estas variables es igual para todos los metodos, p.e realizar una conexión a una base de datos.

En nuestro caso, los métodos son muy sencillos y consiste en inicializar el int[] que vamos a utilizar en todos los métodos.

Ejecutar las pruebas

A continuación, se muestran dos formas de ejecutar los test unitarios:

- TestRunner de JUnit

JUnit proporciona varios TestRunner, como junit.textui.TestRunner (muestra los resultados en modo texto) o junit.swingui.TestRunner (muestra los resultados gráficamente).

java –cp junit-version.jar junit.textui.TestRunner
java –cp junit-version.jar junit.swingui.TestRunner

Nos aparece una ventana donde indicamos el nombre del caso de preuba que queremos ejecutar (o lo elegimos de una lista), y luego pulsamos Run:

La barra verde aparece si las pruebas han ido bien, y si no aparece en rojo. En la pestaña Failures podemos ver que pruebas han fallado, y en Test Hierarchy se muestra todas las pruebas realizadas, y los resultados de cada una. En el cuadro inferior nos aparecen los errores que se han producido en la pruebas.

Para ejecutar el TestRunner u otro ejecutor de pruebas, podemos también definirnos un método main en nuestra clase de prueba que lo lance, en nuestro caso:

public static void main(String[] args){
       String[] nombreTest = {TestArrayWrapper.class.getName()};
       Junit.swingui.TestRunner.main(nombresTest);
}

Vemos que al main del TestRunner se le pueden pasar como parametros los nombres de las clases de prueba que queremos ejecutar.

El TestRunner junit.swingui.TestRunner a partir de la distribución 4.x fue eliminado por decisión del core de JUnit debido a que existen plugins para los IDEs más utilizados (Eclipse, NetBeans, …).

- Ejecución desde Eclispe

Antes de comenzar a detallar como crear y ejecutar los test unitarios desde Eclipse, vamos a mostrar la estructura de carpetas.

Teóricamente, la clase de pruebas debe crearse en el mismo paquete  donde se encuentra nuestra clase. Esto nos permitirá tener acceso a las variables declaradas sin identificador de acceso, sin necesidad de un metodo alterno como un setter. Esto es correcto  para proyectos pequeños con pocas clases, pero en proyectos más grandes tiene inconvenientes.

• El paquete tendra el doble de clases
• Aumenta la dificultad de ‘depurar’ el paquete, ya que antes de entregarlo al cliente debemos encargarnos de eliminar esas clases, siel cliente no las desea.
• La búsqueda de un archivo en particular se vuelve dificil al tener más archivos donde hacerlo.

Un método común para hacer pruebas es crear un directorio con una estructura paralela a nuestro directorio. De esta manera, la estructurade carpetas quedaría de las siguiente manera:

/src/main/utils   –>  /src/test/utils

/src/main/date   –> /src/test/date

/src/main/dao    –> /src/test/dao

Una vez determinada la estructura de directorios y partiendo de que se dispone de un proyecto Eclipse previamente creado, se van a determinar los pasos a seguir para la utilización de JUnit desde Eclipse. Eclipse incorpora opciones para poder trabajar con JUnit desde él.

Al proyecto Java creado en Eclipse, debemos añadir la libreria de JUnit en el Build Path. Para ello  se realiza click con el botón derechos  sobre el proyecto, aparece un desplegable, realizamos click sobre Properties y a continuación sobre Java Build Path seleccionamos la pestaña Libraries.

Nos apareceran varias opciones Add Jars, Add External Jars …, como se va añadir la libre junit-version.jar,  se debe seleccionar Add Jars si la libreria se encuentra en alguna de las carpetas del proyecto a probar, si la librería se encuentra en cualquier otra ubicación se debe seleccionar Add External Jars.

En la siguiente imagen podemos ver como añadir la librería junit-4.5. jar a nuestro proyecto:

Una vez asociado el jar, se crean los paquetes y las clases para realizar las pruebas. Desde el menú File–>New–>Other–>JUnit–>TestCase, Eclipse crear una clase de pruebas, para ello se debe incluir una serie de datos como son la carpeta y el paquete donde lo vamos a crear, el nombre de la clase de pruebas, la superclase (junit.framework.TestCase), la clase sobre la que vamos a realizar las pruebas, y una serie de valores opcionales.

Llegados a este punto ya podemos implementar nuestra clase de pruebas como se mostro al comienzo del post. Una vez definida la clase de prueba, vamos a ejecutar las pruebas, para ello se pulsa el botón derecho  sobre la clase de prueba, y se selecciona  Run –> Run As –> JUnit Test.

A continuación se deben analizar los resultados obtenidos. Como se puede comprobar la prueba realizada no se completo con éxito. De 3 metodos solamente uno se ejecuto satisfactoriamente (testSize).

JUnit indica que el método testToString tiene errores y testSetElementAt se ejecuto con Failure. La diferencia entre Error y Failure es que si se produjo un Error es porque efectivamente existe un error en ejecución en nuestro caso en el método testToString se intento acceder a un elemento 10 de un arrary que solamente tiene definidos 5 elementos.

Para ver la excepción enviada por Java, basta con pulsar sobre el método testToString y en la sección Failure Trace nos mostrar la traza de error.

En el caso de Failure, la ejecución del método se realizo correctamente, esto significa que no ha devuelto ninguna excepción, pero la salida retornada no era la esperada, por tanto no cumple e l Assert establecido en el método de prueba. De igual manera si se selecciona el método con Failure, automaticamente nos aparece la traza, en nuestro caso no indica el siguiente mensajes:

junit.framework.AssertionFailedError: expected <100> but was <99>

Lo cual significa que la salida espera era 100 y el valor retornado fue 99. Una vez realizados los cambios para solucionar tanto los errores como los failures, se vuelve a lanzar los test.

Conclusiones

JUnit es una herramienta Open Source para la realización de test unitarios en la fase de desarrollo para el entorno Java.

Es la herramienta de test más utilizada en entornos Java, lo suficientemente madura para su implantación en entornos comerciales y con un coste cero.

Por todo ello, los principales IDEs de desarrollo (Eclipse, NetBeans, RAD, etc) incorporan plugins para  su utilización.

Además es complementaria con otras herramientas de pruebas como Cobertura, el cual facilita la creación de informes HTML y XML de cobertura de las pruebas realizadas mediante JUnit (% de código probado, % métodos correctos, errores y failures, líneas de código probadas, etc) en un proyecto.

Salu2. Héctor.