Las pruebas

Introducción

Cuando un cliente pide un desarrollo, hay unas especificaciones que describen las funcionalidades de nivel superior en forma de «casos concretos de uso». Este documento servirá más tarde para validar los desarrollos realizados. Estos casos de uso van a poner en acción numerosos objetos desarrollados por el equipo. Estos objetos se van a comunicar entre ellos con los métodos, siguiendo una cronología cuidadosamente pensada durante el análisis. Cada intercambio se realizará la mayor parte del tiempo con argumentos de «ida» y «vuelta». Los rangos admisibles de estos argumentos serán conocidos y estos objetos por lo general funcionarán perfectamente bien cuando reciben lo que se espera, en el momento en que se espera. Pero ¿qué pasará cuando se exceda el tiempo o los argumentos que se pasan estén fuera de los límites?

La solidez de una aplicación se muestra en los casos extremos, gracias a operaciones adaptadas para corregir los defectos y una correcta protección de los datos. Para conseguir este grado de fiabilidad, antes que cualquier otra cosa, cada eslabón de la cadena debe permanecer estable, independientemente de sus condiciones de explotación. Para esto, hay que llevarlos más allá de sus propios límites. El desarrollador deberá imaginar los peores casos...

Entorno de ejecución de las pruebas unitarias

Siempre es posible escribir «pequeñas aplicaciones» autónomas que van a permitir verificar los objetos de la futura «gran aplicación». Por ejemplo, un código que se ha cargado en una consola podrá instanciar la clase que se tiene que probar y, a continuación, desencadenar una serie de llamadas que muestren mensajes de error o escriban los resultados en un archivo. Es posible, pero no muy práctico.

IntelliJ IDEA, con el entorno de pruebas Java JUnit 5, simplifica la redacción, ejecución y análisis de las pruebas unitarias. No hay necesidad de «pequeñas aplicaciones» autónomas; IntelliJ IDEA ofrece directamente la preparación de un conjunto de pruebas, que el desarrollador podrá reproducir en su totalidad, en grupo (playlist) o individualmente, gracias al explorador de pruebas. Los resultados de las pruebas se resumen en una vista tipo «árbol», que utiliza los colores amarillo y verde y permite ir rápidamente a la línea de código que ha fallado en caso de error. Es posible ejecutar pruebas en modo Debug y, por lo tanto, «trazar» los métodos llamados en los objetos que se están probando.

A continuación se muestra...

El proyecto con pruebas unitarias

Las pruebas son métodos de clases que se añaden, la mayor parte de las veces, al proyecto que contiene las clases que se deben probar, ayudándose para ello de los asistentes de IntelliJ IDEA.

package demo.prueba;  
  
public class Vector {  
  
   private int x;  
   private int y;  
  
   public int getX() {  
       return x;  
   }  
  
   public void setX(int x) {  
       this.x = x;  
   }  
  
   public int getY() {  
       return y;  
   }  
  
   public void setY(int y) {  
       this.y = y;  
   }  
  
   public void Agregar(Vector v)  
   {  
       x += v.x;  
       y += v.y;  
   }  
} 

La funcionalidad de esta clase...

La clase de pruebas

El código de partida de nuestra clase de prueba es el siguiente:

package demo.prueba;  
import org.junit.jupiter.api.test;  
  
import static org.junit.jupiter.api.Assertions.*;  
 class VectorPrueba {  
  
   @Prueba  
   void agregar() {  
   }  
} 

En él encontramos el paquete que contiene la clase VectorPrueba que, en sí mismo, contiene el método agregar.

Cada método de pruebas se debe preceder por el atributo @Prueba, que lo distinguirá de otros eventuales métodos de la misma clase.

Contenido de un método de prueba

La prueba se va a ejecutar directamente en el entorno de desarrollo y, por lo tanto, no necesita método main de una clase ni un proyecto particular. El código del método de prueba debe instanciar la clase destino, llamar a uno de sus métodos y, a continuación, validar el comportamiento esperado. Normalmente, en el marco de pruebas unitarias, solo debe tener una acción sobre el objeto por cada prueba.

Por ejemplo, para un método Sumar, la prueba comprueba que, si se pasan 2 y 3 como argumentos, entonces el resultado devuelto será 5.

Las comprobaciones usan la clase Assertions del paquete org.junit.jupiter.api, que ofrece una colección de métodos que tienen servicios mucho más completos que los asociados a la palabra clave assert, utilizada hasta entonces en este libro.

Entre este juego de métodos se encuentra el método assertTrue y sus sobrecargas.

(extracto de http://junit.org/junit5/docs/current/api/org/junit/jupiter/api/Assertions.html)

De esta forma, este método permite comprobar que una condición es verdadera y, si no es el caso, devolver un mensaje en el explorador de pruebas.

Ejemplo de...

Operaciones de preparación y limpieza

La ejecución de las pruebas se puede preceder por operaciones de inicialización y seguir por operaciones de «limpieza». Estas operaciones opcionales se escriben en los métodos que utilizan atributos especiales, que definen en qué momento se ejecutan durante el script.

Extracto de código que muestra la sintaxis de todos los métodos de inicialización

package demo.prueba;  
  
import org.junit.jupiter.api.*;  
  
public class OtrasPruebas {  
  
   public OtrasPruebas(){  
       System.out.println("Constructor de la clase de pruebas"); 
   }  
  
   @BeforeAll  
   public static void Inicialmente(){  
       System.out.println("Antes de lanzar las pruebas (...)");  
   }  
  
   @AfterAll  
   public static void Posteriormente(){  
   ...

Las pruebas con argumentos externos

Imaginemos que vamos a probar el comportamiento de un método en centenares de casos de uso. Escribir y mantener la colección de información en el código será difícil y cualquier cambio necesitará la recompilación de las pruebas: esto no es práctico. Externalizar sus listas en archivos y, a continuación, realizar su carga e iteraciones en la prueba en sí misma no es factible, pero ¿cuál es la función de la prueba? Basarse en el entorno de desarrollo para alimentar nuestras pruebas con datos es, de largo, la solución más confortable y esto es lo que nos ofrece JUnit 5. Se habla por tanto de «data-driven unit tests».

La demostración que sigue utiliza una colección en formato CSV (Comma-Separated Values). Se trata de un archivo en formato texto muy sencillo, donde cada línea representa una colección de argumentos separados por comas. Podemos fácilmente obtener un archivo .csv a partir de un archivo Excel, gracias a su función de exportación.

package demo.prueba;  ...

Ejercicio

String iniciales = ClaseCadena.DevuelveIniciales("Andreas Dulac"); 
// iniciales debe contener "A.D." 

package demo.prueba;  
  
import static org.junit.jupiter.api.Assertions.*;  
  
class ClaseCadenaPrueba {  
  
   @org.junit.jupiter.api.test  
   void PruebaCasoNormal() {  
       String iniciales = ClaseCadena.DevuelveIniciales 
("Andreas Dulac");  
   ...