Pruebas y Spring

Introducción

La preocupación centrada en las pruebas es fundamental para los desarrollos actuales. Cada vez se utiliza más el TDD (Test-Driven Development o desarrollo basado en pruebas), que consiste en que, al mismo tiempo que se escriben nuestros programas, se escriben también las pruebas unitarias antes de escribir el código fuente del software. Desde hace algún tiempo, también se han utilizado BDD (Behavior Driven Development), que son una evolución del TDD con el que las pruebas se describen a través de frases, por ejemplo, en castellano o inglés, con una sintaxis particular, que posteriormente se procesan con un framework como Cucumber. También existen los ATDD (Acceptance Test-Driven Development), para los que los criterios de aceptación se transcriben en las pruebas.

Spring ofrece diferentes API que simplifican la implementación de pruebas unitarias (TU) y de integración (TI). Es necesario verificar y probar todo lo que vale la pena probar. Si tiene problemas al escribir los TU o TI, es porque tiene que volver a trabajar (refactorizar) su código. Una buena práctica consiste en escribir la prueba al mismo tiempo que la clase que se está probando, y algunas veces incluso codificar las pruebas antes de implementar los métodos que se están probando, para que la arquitectura de la aplicación sea compatible con las pruebas. Las pruebas...

Los mock objects

Cuando probamos una clase, queremos centrar nuestras pruebas en esa clase y tenemos que encontrar un sistema para no probar el resto de las clases que interactúan con la que se está probando. Podemos usar objetos simulados llamados mocks para no tener que invocar los objetos reales, lo que haría necesario un contexto de ejecución demasiado grande.

Spring ofrece un conjunto muy completo de mocks. Son más fáciles de usar que los mocks de EasyMock y MockObjects. A menudo, se utilizan con el framework Mockito (http://site.mockito.org/).

public class Vehiculo { 
[accesorios] 
   private long id; 
   private String modelo; 
} 

final Vehiculo persona = new Vehiculo();  
ReflectionTestUtils.setField(persona, "id", new Long(99), 
long.class); 
assertEquals("id", 99L, persona.getId());  
ReflectionTestUtils.setField(persona, "modelo", null, String.class); 
assertNull("modelo", persona.getModelo()); 
try {  
   ReflectionTestUtils.setField(persona, "id", null, long.class); 
   fail("Debería generar una excepción"); 
} catch (IllegalArgumentException aExp) { 
   assert (aExp.getMessage() 
               .contains("IllegalArgumentException")); ...

Los frameworks de test JUnit y TestNG

Spring ha integrado los dos frameworks más completos en la actualidad para simplificar su uso. Construir un entorno para ejecutar nuestras pruebas se convierte en un juego de niños y es posible cargar en la memoria solo lo mínimo para poder hacer dichas pruebas. Hay dos versiones de JUnit: la 4 y la 5, llamada Jupiter. Es posible mezclar la sintaxis de JUnit4 con Jupiter para proyectos híbridos o en curso de migración. En adelante en este capítulo, vamos a ver las pruebas de integración que utilizan Spring y JUnit. Las pruebas que usan TestNG son similares a las que usan JUnit y no se van a detallar.

Las pruebas unitarias se realizan fuera de Spring y, por lo tanto, no se tratan aquí.

Las pruebas de integración son relativamente complejas porque queremos crear el contexto mínimo que contenga el mínimo de beans Spring que son necesarios y suficientes para probar la parte que nos interesa.

@RunWith(SpringJUnit4ClassRunner.class) 
@TestExecutionListeners({}) 
public class SimpleTest { 
    @Test 
public void testMethod() { 
[...] 
} 

@IfProfileValue(name="java.vendor", value="Oracle Corporation") 
@Test 
public void testProcesoConJvmOracle() {  
 
@IfProfileValue ( name = "test-groups" , values ={ "unit-tests" , 
"integration-tests" }) 
@Test 
 public  void 
testProcessWhichRunsForUnitOrIntegrationTestGroups() { 
     // una determinada lógica que debería funcionar solo 
     // para las pruebas unitarias y de integración