Hibernación Caché de datos de segundo nivel y prueba de integración/aceptación

Question

Tengo una aplicación web JPA/Hibernate/Spring/Tomcat con caché de datos de segundo nivel habilitada por motivos de rendimiento. ¡Y el caché hace su trabajo muy bien!

También tengo un conjunto de pruebas Cucumber que agrega algunos datos de prueba directamente a la base de datos de la aplicación y luego realiza algunos pasos de Selenium. Por supuesto, falla ya que la aplicación no ve las actualizaciones debido a la memoria caché de segundo nivel.

Sé que puedo hacer una compilación especial para probar con la caché desactivada (pasando alguna propiedad booleana para el filtrado de Maven o similar) Pero hay muchas entidades anotadas @Cache, por lo que deshabilitar la caché hace que la aplicación falle con la excepción "Segundo el nivel de caché no está habilitado ".

Otro enfoque podría ser utilizar ehcache remoto para borrar la memoria caché o configurarla con cero vida de objeto o similar.

También puedo crear mis datos de prueba usando solo la interfaz de usuario de la aplicación, pero esto agrega complejidad innecesaria a los casos de prueba, así que prefiero escribirlos en la base de datos antes de ejecutar la prueba.

¿Alguien podría compartir su enfoque a las aplicaciones de prueba de integración con la memoria caché de datos de segundo nivel habilitada?

Answer 1

Ya que está hablando de pruebas funcionales a través de Selenium, debería considerar su aplicación como una caja negra y probarla como Selenium en realidad era un Usuario. Por lo tanto, debe pasar datos a través de la interfaz web y luego probar cómo la aplicación lo procesa y lo muestra después.

Alternativa a tales pruebas funcionales de toda la aplicación será un Desarrollo Dirigido por Comportamiento con pruebas para diferentes componentes. El componente aquí es un flujo que comienza desde que su controlador termina con DAO (por lo general, DAO se burla de tales pruebas, lo que hace que pasen muy rápido, pero no prueba el trabajo con la base de datos). En este caso, tiene un pequeño conjunto de pruebas de entorno completo y un gran conjunto de pruebas de BDD.

Answer 2

que tenían un requisito de implementar el almacenamiento en caché de sólo lectura por unos granos como país, región, etc ..

para comprobar si realmente están siendo cacheados He escrito una prueba integración con el uso de la primavera. La prueba no es tan apropiada, es solo una verificación de lo que quería obtener. Puedes usar esto como una pista e implementar la tuya.

Puede leer here para obtener un artículo sobre cómo escribir una prueba de integración utilizando la primavera.

@Configurable(autowire = Autowire.BY_NAME) 
@RunWith(SpringJUnit4ClassRunner.class) 
@ContextConfiguration(locations = { "classpath:applicationContext.xml" }) 
public class HibernateCachingTestIntg { 

    @Autowired 
    private ConfigurationDAO configurationDAO; 

    @Autowired 
    private CountryDAO countryDAO; 

    @Test 
    public void testGetCountries() { 
     for (int i = 0; i < 5; i++) { 
      StopWatch sw = new StopWatch("C"); 
      sw.start(); 
      countryDAO.listCountries(); 
      sw.stop(); 
      System.out.println(sw); 
     } 

    } 

    @Test 
    public void testGetRegionList() { 

     for (int i = 0; i < 5; i++) { 
      StopWatch sw = new StopWatch("R"); 
      sw.start(); 
      configurationDAO.getRegionList(); 
      sw.stop(); 
      System.out.println(sw); 
     } 

    } 
} 

Y aquí está la salida: -

StopWatch 'C': running time (millis) = 217; [] took 217 = 100% 
StopWatch 'C': running time (millis) = 15; [] took 15 = 100% 
StopWatch 'C': running time (millis) = 16; [] took 16 = 100% 
StopWatch 'C': running time (millis) = 15; [] took 15 = 100% 
StopWatch 'C': running time (millis) = 16; [] took 16 = 100% 

StopWatch 'R': running time (millis) = 201; [] took 201 = 100% 
StopWatch 'R': running time (millis) = 15; [] took 15 = 100% 
StopWatch 'R': running time (millis) = 0; [] took 0 = 0% 
StopWatch 'R': running time (millis) = 16; [] took 16 = 100% 
StopWatch 'R': running time (millis) = 15; [] took 15 = 100% 

Como se puede ver aquí, la consulta tarda más tiempo para ejecutar por primera vez y menos tiempo epílogos. Si activa el registrador de consultas, puede ver que el SQL se activa solo por primera vez.

Answer 3

Aunque es preferible realizar pruebas de aceptación independientes en la base de datos, requiere demasiada reescritura, así que decidí simplemente crear implementaciones muy simples de interfaces org.hibernate.cache.Cache y org.hibernate.cache.CacheProvider que no hacen nada y actúa como un caché siempre vacío.

La compilación de prueba reemplaza la caché real con esta nueva que hace felices tanto a las anotaciones de hibernación como a los pasos de BDD.

Answer 4

Si necesita probar la memoria caché de segundo nivel con la prueba unitaria, debe asegurarse de cerrar la sesión y abrirla cada vez que llame al método dao. De lo contrario, utilizará la memoria caché de primer nivel que existe solo en el ámbito de una sesión de hibernación actual/actual.