Resumen QA&TEST 2010 (second day)

On 1 noviembre, 2010, in Conferencias, by twiindan

Despues de un muy buen comienzo de las jornadas, llego el segundo día con unos contenidos igual de interesantes que el primer día.

El día empezo con la Keynote de Tammy Noergaard donde explico los principales errores que cometemos dividido en varios niveles, desde errores que se producen por parte de planificación o dirección (como no tener en cuenta los deadlines a la hora de planificar, o escoger el lenguaje de programación correcto a la hora de diseñar y programar la aplicación, o no definir la estrategia de testing desde el primer día). Una keynote muy instructiva donde se nos recordaba errores que siempre cometemos y que conviene siempre tener presentes (creo que me haré una lista y la colgaré en mi sitio para no volverlos a cometer).

Seguidamente se realizaron varias presentaciones dentro de dos tracks (Testing Safety Critical Systems y Requirment Management). Dentro del primero destacar la conferencia sobre análisis estático, y varios problemas o errores que pueden surgir si este no se realiza.  También una gran presentación por parte de Bryan Bakker sobre diseño de tests automáticos emfatizando sobretodo la parte de test de integración, generalmente otro tipo de testing un poco olvidado (por lo menos en mi organización).

Despues de todo esto un descanso bien merecido y una gran comida a base de varios pescados en el restaurante del Palacio de Euskalduna.

Ya con el estomago lleno, volvian las conferencias de nuevo con dos tracks diferentes (People in Software Testing y Testing Techniques & Testing Proccess). Yo me tuve que quedar en la primera de ellas ya que mi conferencia estaba en este track.  Muy destacable el toque de humor de Tony Simms a la hora de narrar los diferentes problemas que podia tener un project manager y que generalmente no tenemos en cuentaa. Seguidamente una descafeinada presentación en la que estaba totalmente de los nervios! Despues de todo este tiempo, fue el momento, 40 intensos minutos donde explique las funciones que se realizan dentro de Diagnostic Grifols, por suerte los nervios se fueron poco a poco y en general la gente por lo menos no se dormia. Una vez ya finalizado, 2 preguntas (una de ellas con un poco de mala leche) y un gran aplauso por la presentación!

Para acabar la jornada se realizó un interesante debate donde hubo varios temas centrales como las metodologias ágiles o las certificaciones, dos temas muy candentes actualmente.

ya acabada la jornada, muchas preguntas sobre varios procesos de mi presentación por parte de varias personas y a descansar al hotel.

Ya por la noche una interesante cena de gala donde los organizadores nos regalarón un buen menu y unas cuantas copichuelas en un bar de copas, lo ideal para soltarse un poco más la lengua y acabar de perfeccionar el ingles! Eso si, no muy tarde a dormir que aun faltaba el tercer día!

Logging para Junit

On 22 junio, 2010, in Consejos, by twiindan

El otro día vi como se estaban peleando los desarrolladores con unos Test Unitarios hechos en Junit que no entiendian porque fallaban y se excusaban en que no tenían ningún log cuando los desarrollaban.

Empece a pensar un poco, y llegue a la conclusión que al fin y al cabo Junit no deja de ser código java puramente y que por lo tanto se podría utilizar igualmente la librería que utilizamos para el desarrollo de la aplicación log4j.

Dentro del frameework de Log4j está el concepto de “Appenders” donde se le indica el destino en el que se escribirán las trazas de log (consola, fichero de texto…). En nuestro caso, estos Appenders se configuran durante la inicialización de la aplicación, por lo que en los tests unitarios se debería inicializar en algo parecido.

Para ello dependiendo de nuestra arquitectura de Test Unitarios de Junit podemos optar por varias opciones:

  • Si queremos inicializar el log para un test o varios en particular hay que realizar la llamada desde los métodos “setUp” y realizar un logging shutdown en el método “tearDown”:

public void setUp() {
BasicConfigurator.configure();
}

public void tearDown() {
LogManager.shutdown();
}

  • Si tenemos los tests en Test Suites lo mejor será que inicialicemos los logs en un método de inicialización @beforeclass:
public class AllTests {
    @BeforeClass
    public static void startup() {
        BasicConfigurator.configure();
    }
}

Yo personalmente prefiero la segunda opción ya que de esta manera podemos ejecutaremos la inicialización de los logs una única vez y siempre antes de la ejecucción de los tests, por lo que no tendremos problemas de encontrarnos código duplicado.

Tagged with: