Tests d'intégration de base de données avec Spring Boot et Testcontainers

1. Présentation

Avec Spring Data JPA, vous pouvez facilement créer des requêtes de base de données et les tester à l'aide de la base de données H2 intégrée.

Mais parfois, tester sur une vraie base de données est beaucoup plus utile , surtout si nous utilisons des requêtes liées à une implémentation de base de données spécifique.

Dans ce guide, nous montrerons comment utiliser Testcontainers pour les tests d'intégration avec Spring Data JPA et la base de données PostgreSQL.

Dans l'article précédent, nous avons créé plusieurs requêtes de base de données, en utilisant principalement l'annotation @Query , que nous testons actuellement.

2. Configuration

Pour utiliser la base de données PostgreSQL dans nos tests, nous devons ajouter la dépendance Testcontainers des seuls tests et le pilote PostgreSQL à notre fichier pom.xml :

<dependency> <groupId>org.testcontainers</groupId> <artifactId>postgresql</artifactId> <version>1.10.6</version> <scope>test</scope> </dependency> <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> <version>42.2.5</version> </dependency> 

Nous créerons également un fichier application.properties dans le répertoire des ressources de test, dans lequel nous définirons l'utilisation de la classe de pilote requise pour Spring, ainsi que la création et la suppression du schéma de base de données à chaque exécution du test:

 spring.datasource.driver-class-name=org.postgresql.Driver spring.jpa.hibernate.ddl-auto=create-drop 

3. Test unitaire

Pour commencer à utiliser une instance PostgreSQL dans une seule classe de test, vous devez créer une définition de conteneur, puis utiliser ses paramètres pour établir la connexion:

 @RunWith(SpringRunner.class) @SpringBootTest @ContextConfiguration(initializers = {UserRepositoryTCIntegrationTest.Initializer.class}) public class UserRepositoryTCIntegrationTest extends UserRepositoryCommonIntegrationTests { @ClassRule public static PostgreSQLContainer postgreSQLContainer = new PostgreSQLContainer("postgres:11.1") .withDatabaseName("integration-tests-db") .withUsername("sa") .withPassword("sa"); static class Initializer implements ApplicationContextInitializer<ConfigurableApplicationContext> { public void initialize(ConfigurableApplicationContext configurableApplicationContext) { TestPropertyValues.of( "spring.datasource.url=" + postgreSQLContainer.getJdbcUrl(), "spring.datasource.username=" + postgreSQLContainer.getUsername(), "spring.datasource.password=" + postgreSQLContainer.getPassword() ).applyTo(configurableApplicationContext.getEnvironment()); } } } 

Dans l'exemple ci-dessus, nous avons utilisé @ClassRule de JUnit pour configurer le conteneur de base de données avant d'exécuter les méthodes de test . Nous avons également créé une classe interne statique qui implémente ApplicationContextInitializer . Enfin, nous avons appliqué l'annotation @ContextConfiguration à notre classe de test avec la classe d'initialisation comme paramètre.

Une fois ces trois étapes terminées, nous pouvons définir les paramètres de connexion avant de publier le contexte Spring.

Nous utilisons maintenant deux requêtes UPDATE de l'article précédent:

 @Modifying @Query("update User u set u.status = :status where u.name = :name") int updateUserSetStatusForName(@Param("status") Integer status, @Param("name") String name); @Modifying @Query(value = "UPDATE Users u SET u.status = ? WHERE u.name = ?", nativeQuery = true) int updateUserSetStatusForNameNative(Integer status, String name); 

Et testez dans un environnement d'exécution optimisé:

 @Test @Transactional public void givenUsersInDB_WhenUpdateStatusForNameModifyingQueryAnnotationJPQL_ThenModifyMatchingUsers(){ insertUsers(); int updatedUsersSize = userRepository.updateUserSetStatusForName(0, "SAMPLE"); assertThat(updatedUsersSize).isEqualTo(2); } @Test @Transactional public void givenUsersInDB_WhenUpdateStatusForNameModifyingQueryAnnotationNative_ThenModifyMatchingUsers(){ insertUsers(); int updatedUsersSize = userRepository.updateUserSetStatusForNameNative(0, "SAMPLE"); assertThat(updatedUsersSize).isEqualTo(2); } private void insertUsers() { userRepository.save(new User("SAMPLE", "email@example.com", 1)); userRepository.save(new User("SAMPLE1", "email2@example.com", 1)); userRepository.save(new User("SAMPLE", "email3@example.com", 1)); userRepository.save(new User("SAMPLE3", "email4@example.com", 1)); userRepository.flush(); } 

Dans le scénario ci-dessus, le premier test réussit et le second lève une exception InvalidDataAccessResourceUsageException avec le message:

 Caused by: org.postgresql.util.PSQLException: ERROR: column "u" of relation "users" does not exist 

Si nous exécutions les mêmes tests en utilisant la base de données H2 intégrée, les deux réussiraient, mais PostgreSQL n'accepte pas les alias dans l'instruction SET. Nous pouvons résoudre rapidement la demande en supprimant l'alias problématique:

 @Modifying @Query(value = "UPDATE Users u SET status = ? WHERE u.name = ?", nativeQuery = true) int updateUserSetStatusForNameNative(Integer status, String name); 

Cette fois, les deux tests ont réussi. Dans cet exemple, nous avons utilisé Testcontainers pour identifier un problème avec une requête native qui ne serait autrement détecté qu'après avoir accédé à la base de données de production . Il convient également de noter que l'utilisation de requêtes JPQL est généralement plus sûre, car Spring les traduit correctement en fonction du fournisseur de base de données utilisé.

4. Instance de base de données partagée

Dans la section précédente, nous avons décrit comment utiliser les conteneurs de test dans un seul test. Dans des cas réels, je voudrais utiliser le même conteneur de base de données dans plusieurs tests en raison du temps de lancement relativement long.

Créons une classe commune pour créer un conteneur de base de données en héritant de PostgreSQLContainer et en remplaçant les méthodes start () et stop () :

 public class BaeldungPostgresqlContainer extends PostgreSQLContainer<BaeldungPostgresqlContainer> { private static final String IMAGE_VERSION = "postgres:11.1"; private static BaeldungPostgresqlContainer container; private BaeldungPostgresqlContainer() { super(IMAGE_VERSION); } public static BaeldungPostgresqlContainer getInstance() { if (container == null) { container = new BaeldungPostgresqlContainer(); } return container; } @Override public void start() { super.start(); System.setProperty("DB_URL", container.getJdbcUrl()); System.setProperty("DB_USERNAME", container.getUsername()); System.setProperty("DB_PASSWORD", container.getPassword()); } @Override public void stop() { //do nothing, JVM handles shut down } } 

Laissant la méthode stop () vide, nous permettons à la JVM de gérer la complétion du conteneur par elle-même. Nous implémentons également un simple singleton, dans lequel seul le premier test démarre le conteneur, et chaque test suivant utilise une instance existante. Dans la méthode start () , nous utilisons System # setProperty pour enregistrer les paramètres de connexion dans les variables d'environnement.

Nous pouvons maintenant les écrire dans le fichier application.properties :

 spring.datasource.url=${DB_URL} spring.datasource.username=${DB_USERNAME} spring.datasource.password=${DB_PASSWORD} 

Maintenant, nous utilisons notre classe d'utilité dans la définition de test:

 @RunWith(SpringRunner.class) @SpringBootTest public class UserRepositoryTCAutoIntegrationTest { @ClassRule public static PostgreSQLContainer postgreSQLContainer = BaeldungPostgresqlContainer.getInstance(); // tests } 

Comme dans les exemples précédents, nous avons appliqué l'annotation @ClassRule au champ avec la définition de conteneur. Ainsi, les paramètres de connexion DataSource sont remplis avec les valeurs correctes avant de créer le contexte Spring.

Nous pouvons maintenant implémenter plusieurs tests en utilisant la même instance de base de données en définissant simplement le champ avec l'annotation @ClassRule créée à l'aide de notre classe utilitaire BaeldungPostgresqlContainer .

5. Conclusion

Dans cet article, nous avons montré des méthodes de test sur une base de données de production à l'aide de Testcontainers.

Nous avons également examiné des exemples d'utilisation d'un seul test à l'aide du mécanisme ApplicationContextInitializer de Spring, ainsi que l'implémentation d'une classe pour réutiliser une instance de base de données.

Nous avons également montré comment les Testcontainers peuvent aider à identifier les problèmes de compatibilité entre plusieurs fournisseurs de bases de données, en particulier pour les requêtes natives.

Comme toujours, le code complet utilisé dans cet article est disponible sur GitHub .