Référentiels de bases de données testables dans Kotlin | de Andrew O’Hara | décembre 2022

En exigeant la DataSource à injecter dans notre JdbcCatsRepo, nous pouvons l’utiliser pour la production et les tests, de manière transparente. Dans notre main méthode, nous la configurons avec un simple DataSource ; bien qu’en production, vous utiliserez probablement le pool de connexion de votre choix.

Mettons maintenant en œuvre un CatsRepoContract pour notre JdbcCatsRepo. Nous aurons besoin d’une base de données de test, et bien qu’il soit possible d’utiliser un conteneur MySQL, je préfère utiliser la base de données H2 incroyablement légère et purement java ; en mode de compatibilité MySQL. Une fois que nous avons démarré une base de données en mémoire, nous pouvons créer la table et l’injecter dans notre JdbcCatsRepo .

C’était assez facile; mais comment cela fonctionnerait-il pour un ORM plus compliqué?

JetBrains/Exposé est un ORM SQL très apprécié ; il est expressif, sûr et léger. C’est un excellent choix à utiliser pour les modèles de données non triviaux. Mettons en place un CatsRepo .

Dans ce cas, notre ExposedCatsRepo nécessite une exposition Database être injecté; qui est étroitement liée à la DataSource dans l’exemple précédent. Notre main méthode est très similaire à l’exemple JDBC ci-dessus, nous avons un MySQL DataSource convertissez-le en Exposed Database et l’injecter dans ExposedCatsRepo .

Mise en place d’unCatsRepoContract est tout aussi simple que le JDBC brut ; nous utiliserons la même base de données H2 en mémoire, utilisez le Exposed SchemaUtils pour créer la table, puis injectez-la dans le ExposedCatsRepo .

Maintenant que nous avons couvert quelques options SQL ; passons à DynamoDB.

La Client amélioré pour Dynamo DB fournit une excellente interface de mappage pour travailler avec les éléments Dynamo DB. Cependant, comme il s’agit d’un SDK Java, le mappeur ne fonctionne pas avec les classes Kotlin Data idiomatiques ; j’ai sorti un plugin pour contourner cette limitation, que nous utiliserons ici.

Cette mise en œuvre de CatsRepo nous oblige à créer un DynamoCat classer; annoté avec des conseils pour que le mappeur génère un schéma.

Notre V2DynamoCatsRepo nous oblige à injecter un DynamoDbTable . Dans notre main ci-dessus, nous créons un vrai client Dynamo DB et définissons la table à injecter.

Afin de tester le nouveau référentiel, nous devrons simuler DynamoDB. Il y a quelques options pour cela; chacun avec ses propres avantages et inconvénients.

1. Le module de conteneur de test Dynalite – très précis, mais nécessite docker et est lent à s’initialiser
2. oharaandrew314/mock-aws-java-sdk – une implémentation rapide et en mémoire du SDK officiel, mais il manque certaines fonctionnalités avancées
3. http4k/http4k-connect – ou similaire; un émulateur AWS autonome lié à un port TCP local

Pour cet exemple, nous utiliserons oharaandrew314/mock-aws-java-sdk. Il fournit une implémentation entièrement simulée du SDK officiel.

Cette méthode peut fonctionner très efficacement, mais il n’est parfois pas souhaitable d’inclure le SDK officiel gonflé dans le chemin de classe. Pour contourner cela, nous pouvons étudier une alternative.

http4k/http4k-connect a un SDK AWS alternatif et inclut un mappeur Dynamo DB que nous pouvons utiliser pour implémenter un CatsRepo . Étant donné que le SDK est construit sur http4k – dont les créateurs sont de grands fans de testabilité – il inclut un environnement AWS factice efficace pour nos tests.

Il n’y a pas de réflexion dans ce SDK, donc pour implémenter le CatsRepo , nous devons définir les indices primaires et secondaires. Un guide plus détaillé pour ce mappeur est disponible dans le annexes http4k-connect.

La Http4kDynamoCatsRepo nécessite un DynamoDbTableMapper être injecté. Pour notre main méthode, nous nous connecterons au backend AWS officiel et définirons une table à injecter.

Mise en place d’un CatsRepoContract est essentiellement le même que le main méthode. La principale différence est que nous définissons la table dans un client soutenu par un faux environnement DynamoDB.

Avec ces stratégies à votre actif, j’espère que vous pourrez cesser d’ignorer le code de votre base de données lors des tests. Si vous utilisez réellement vos référentiels, vous pouvez avoir une plus grande confiance dans vos services, avec beaucoup moins de tests et de simulations.

Le code source complet de ces exemples est disponible sur GitHub :