Configurar log4j para JUnit

25 05 2009

Es muy habitual que a la hora de programar nuestras aplicaciones utilicemos algún tipo de librería de log. Tradicionalmente hay dos familias log4j (la pionera) y la nativa de Java (java.util.logging) que vino un poco después “inspirándose” bastante en la filosofía del proyecto de Apache.

Personalmente soy usuario de log4j por varios motivos: estuvo disponible antes, es el logging nativo de mi servidor de aplicaciones habitual (JBoss) y me gusta más 😉

Por otro lado, mi manera habitual de desarrollo es TDD, así que el IDE pasa una parte importante del tiempo ejecutando suites de tests JUnit.

Cualquiera de los frameworks de logging que utilicemos tiene el concepto de appender que es el destino en el que se escriben los mensajes. Destinos habituales suelen ser la consola o un fichero, por ejemplo. La configuración de los appenders de una aplicación se suele hacer durante el bootstrap (o la inicialización, si lo preferís) de la misma. Sin embargo cuando estamos corriendo tests, dicha inicialización no se produce así que perdemos todos los mensajes de logging que, si alguien se molestó en escribirlos, seguro que son muy útiles (especialmente cuando estamos desarrollando).

En “modo desarrollo” seguramente tenemos suficiente con una configuración básica en el que todos los mensajes se redirijan a la consola (que obviamente puede estar integrada en nuestro IDE). En el caso de log4j existe el método estático

org.apache.log4j.BasicConfigurator.configure()

que hace precisamente eso (creo recordar que java.util.logging tiene un mecanismo análogo). Ahora sólo resta saber dónde hacer la llamada al método. Obviamente no tiene sentido que lo pongamos en cada TestCase. Como en general agrupamos los diferentes tests en suites, parece que este es un buen lugar para configurarlo. Por ejemplo:

@RunWith(Suite.class)
@Suite.SuiteClasses(value={
    nq.quota.QuotaTest.class,
    nq.quota.FrequencyTest.class,
    })
public class AllTests {
    @BeforeClass
    public static void startup() {
        BasicConfigurator.configure();
    }
}

En el código precedente se ve la configuración de una test suite con JUnit 4 y etiquetamos un método de inicialización como @BeforeClass para asegurarnos que se ejecuta una única vez y antes de que la suite lance todos los tests configurados.

Esta misma idea puede utilizarse para configurar todos aquellos compartidos por los diferentes tests: variables de entorno, conexiones a bases de datos, etc.


		
Anuncios




Bug con el tracker en Ubuntu 9.04 – Jaunty Jackalope

24 05 2009

Como sabéis soy bastante pro-Ubuntu. Me parece un gran entorno de escritorio y de desarrollo y sólo cambio a otros (y dentro de una máquina virtual, por supuesto) ante la falta de sensibilidad de algunos fabricantes de dispositivos (Apple, TomTom, Logitech, por citar algunos) que te obligan a utilizar software no compatible con Linux para utilizar las características avanzadas de dichos dispositivos. También es lamentable que para utilizar algunas páginas web (especialmente de la administración pública) tengas que recorrer al Internet Explorar. Pero bueno, esto es otra guerra.

Hace poco se lanzó la versió Ubuntu 9.04 (alias Jaunty Jackalope) e hice el upgrade hace unas semanas. Los upgrades de Ubuntu también dan gusto: todo se hace de manera automática, no pierdes el control sobre tus cofiguraciones propias (ficheros de configuración de servicios como MySQL, Samba, etc.) y todo funciona correctamente.

No obstante venía observando que a la que la máquina llevaba un rato encendida, se me disparaba el uso de una de las CPU, el ordenador no paraba de rascar disco duro y se recalentaba que daba gusto, de hecho hasta incluso llegar a colgarse en alguna ocasión. La verdad es que hace unos meses le metí mano al hardware del portátil y le metí un disco mucho mayor (como estaba metido en temas de formación necesitaba tener instaladas unas cuantas máquinas virtuales simultáneamente) y mucho más rápido y, que por tanto, se calentaba más y pensé que a lo mejor no había sido muy buena idea… Pero no tenía sentido, porque no había tenido ningún problema antes con el Ubuntu 8.10 y al arrancarlo ahora en modo Windows (sí, soy culpable, tengo una partición nativa Windows para casos de urgencia) tampoco había problema.

Tirando de top en un momento que se disparaba el uso vi que había un proceso comiéndose una CPU entera y accediendo sospechosamente al disco: tracker-indexer. Este proceso se corresponde con la utilidad tracker que es algo parecido al locate de toda la vida, un proceso que analiza el disco, e indexa su contenido para tener un acceso rápido en las búsquedas. Me sorprendió un poco porque creía haberlo desinstalarlo hace mucho tiempo (desde luego no aperecía como antes en la interfaz gnome) y además había instalado el Google Desktop que es un software análogo pero que personalmente me gusta más.

En cualquier caso, el tracker no debería comerse una CPU y llevar el portátil hasta la extenuación por calor del disco duro. Googleando un poco se ve que es un bug conocido en la nueva versión de Ubuntu. La verdad es que no me he molestado mucho en mirar si tiene solución, porque, como he dicho, es un software que no utilizo, así que simplemente he abierto el Synaptic, he buscado el paquete asociado y lo he desinstalado efectivamente y todo solucionado.

Por cierto, con una instalación “limpia” deJaunty Jackalope, el tracker no vien pre-instalado.