Como comentamos en uno de los últimos posts, en las siguientes entregas hablaremos de los testing quadrants que ya introducimos y que descubri en el libro de “Agile Testing”. En esta entrega empezamos con el primero de los testing quadrants.

El Testing Quadrant Q1 es el primero de los quadrantes de testing a tener en cuenta, pero también es posiblemente el testing en el que menos involucrado se encuentra el tester.

Este tipo de testing suele estar muy ligado con la parte tecnológica del proyecto, ya es donde se realizan los unit tests o los tests de integración.

El proposito principal de este testing es ayudar al equipo a entender como debe funcionar el código a realizar, y proporcionar una guia para un correcto diseño de este software.

Generalmente este tipo de testing suele estar muy automatizado, mediante herramientas como xUnit (dependiendo del lenguaje de programación). En este tipo de testing se englobarian las metodologías de diseño como TDD (Testing Drive development).

También es recomendable ejecutar estos tests cuando se realiza una subida de nuevo código para comprobar que no tenga efectos colaterales y detectar posibles errores. Por ese motivo se aconseja introducirlo dentro del sistema de integración continua.

Como ventajas principales  de este tipo de testing podemos destacar tres:

  1. La velocidad de ejecución de los tres es extremadamente rápida por lo que se pueden ejecutar cada vez que se realiza alguna nueva funcionalidad.
  2. Se realizan tests a nivel unitario por lo que se puede llegar a condiciones complicadas de obtener por otro tipo de testing.
  3. Pueden servir como base para otro tipos de testing de más alto nivel como tests automatizados de aceptación o de negocio.

Y en que lugar queda el tester dentro de este tipo de testing? Generalmente los testers no se involucran en los tests unitarios ya que los suelen realizar los programadores.

Sin embargo, en metodologías ágiles, si que es aconsejable que los testers se involucren en este tipo de testing ayudando y guiando a los desarrolladores a diseñar esos tests unitarios. De esta manera el desarrollador puede aprender técnicas para realizar los tests unitarios de forma más eficiente, y el tester puede aprender de desarrollo como funcionan los tests unitarios y entender la forma en la que trabaja el desarrollador.

Recordar que al final el objetivo del equipo es el mismo, entregar un software de calidad, y esta calidad es responsabilidad de todo el equipo. Por eso es importante el soporte continuo entre todo equipo.

Tagged with:  

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: