Comment tester la prise en charge de la mise en cache déclarative de Spring sur les référentiels Spring Data?

Si vous souhaitez tester un aspect technique comme la mise en cache, ne pas utiliser une base de données à tous. Il est important de comprendre ce que vous souhaitez tester ici. Vous voulez vous assurer que, l'invocation de la méthode est à éviter pour l'invocation avec les mêmes arguments. Le référentiel face à une base de données est complètement orthogonale à l'aspect de ce sujet.

Voici ce que je recommande:

1. Mis en place un test d'intégration qui configure déclarative de la mise en cache (ou importations nécessaires bits et des morceaux à partir de votre configuration de production.
2. Configurer un simulacre d'instance de votre référentiel.
3. Écrire un scénario de test pour définir le comportement attendu de la maquette, d'appeler les méthodes et vérifier la sortie en conséquence.

Échantillon

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class CachingIntegrationTest {
//Your repository interface
interface MyRepo extends Repository<Object, Long> {
@Cacheable("sample")
Object findByEmail(String email);
}
@Configuration
@EnableCaching
static class Config {
//Simulating your caching configuration
@Bean
CacheManager cacheManager() {
return new ConcurrentMapCacheManager("sample");
}
//A repository mock instead of the real proxy
@Bean
MyRepo myRepo() {
return Mockito.mock(MyRepo.class);
}
}
@Autowired CacheManager manager;
@Autowired MyRepo repo;
@Test
public void methodInvocationShouldBeCached() {
Object first = new Object();
Object second = new Object();
//Set up the mock to return *different* objects for the first and second call
Mockito.when(repo.findByEmail(Mockito.any(String.class))).thenReturn(first, second);
//First invocation returns object returned by the method
Object result = repo.findByEmail("foo");
assertThat(result, is(first));
//Second invocation should return cached value, *not* second (as set up above)
result = repo.findByEmail("foo");
assertThat(result, is(first));
//Verify repository method was invoked once
Mockito.verify(repo, Mockito.times(1)).findByEmail("foo");
assertThat(manager.getCache("sample").get("foo"), is(notNullValue()));
//Third invocation with different key is triggers the second invocation of the repo method
result = repo.findByEmail("bar");
assertThat(result, is(second));
}
}

Comme vous pouvez le voir, nous faire un peu plus de tests ici:

1. Le plus pertinent de vérifier, je pense, est que le deuxième appel renvoie le premier objet. C'est ce que la mise en cache est tout au sujet. Les deux premiers appels avec la même clé de retourner le même objet, tandis que le troisième appel avec une clé différente résultats dans le réel deuxième invocation sur le référentiel.
2. Nous renforcerons les cas de test qui permet de vérifier que le cache, en réalité, a une valeur pour la première clé. On pourrait même prolonger pour vérifier la valeur réelle. D'autre part, je pense aussi que c'est bien d'éviter de faire comme vous avez tendance à mettre à l'essai plus de l'intérieur du mécanisme, plutôt que le niveau de l'application de comportement.

Points clés à retenir

1. Vous n'avez pas besoin d'aucune infrastructure à mettre en place pour le conteneur de test de comportement.
2. Définition d'un cas de test est facile et simple.
3. De composants bien conçus vous permettent d'écrire des simples cas de test et nécessitent moins d'intégration de la jambe de travail pour les tests.