Pruebas con TestNG: ordenando nuestras pruebas

TestNG es una herramienta de ejecución (y reporte de resultado) de pruebas unitarias. Esta herramienta ofrece una serie de opciones de configuración que permiten un control exhaustivo sobre la ejecución de las pruebas. En ocasiones necesitamos que las pruebas se ejecuten en un cierto orden, primero la carga de contenidos, recuperación, seguido de actualización de los mismos y por último borrado. Estas operaciones claramente requieren orden en su ejecución. JUnit, herramienta por excelencia para ejecución de pruebas unitarias, no ofrece ninguna opción al tester para mantener este orden. Vamos a ver como hacerlo con TestNG y como integrarlo en un proyecto Maven:

Configurar el pom para usar el plugin de TestNG:

…
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>5.7</version>
<scope>test</scope>
<classifier>jdk15</classifier>
</dependency>
…

Configurar TestNG: agruparemos nuestras pruebas en grupos lógicos en el fichero testng.xml en el directorio /src/test/config.

<groups>
<define name=”root”>
<include name=”creacion” />
<include name=”recuperacion” />
<include name=”actualizacion” />
<include name=”borrado” />
</define>
<run>
<include name=”root” />
</run>
</groups>

Anotaciones en las clases de test: mediante anotaciones (Java 1.5) indicaremos a que grupos pertenece cada test y de qué grupos depende se ejecución.

@Test(groups = { "recuperacion", "root" }, dependsOnGroups = { "creacion" } )
public void recuperaEntidad1() {
...

Con esta anotación indicamos a TestNG que ejecute esta prueba despues de ejecutar todas las pruebas que pertenecen al grupo “creacion”.

Si queremos agrupar los reportes de las pruebas en un maven site podemos usar el plugin “maven-surefire-report”.
Aquí hay un pom.xml básico y un testng.xml de ejemplo.

Además del orden de las pruebas hay otros aspectos que típicamente se debe plantear un tester, como la decisión de usar una base de datos en ficheros para las pruebas o, por el contrario, usar la base de datos de desarrollo (base de datos real de la aplicación probada). Esta decisión depende en gran parte del tipo de proyecto. Si se trata de un proyecto en cuyo entorno de despliegue/producción disponemos de una base de datos contra la que podemos hacer las pruebas sin ningún tipo de restricción (tenemos permisos para hacer cualquier cosa), entonces lo mejor es hacer las pruebas contra la base de datos real, de esta forma probamos, además del funcionamiento “unitario” de nuestra aplicación, el link con la base de datos. En caso contrario, tenemos restricciones importantes sobre la base de datos, entonces ejecutaremos las pruebas sobre una base de datos en ficheros o memoria.