Recherche

Coder's IO

Tag

Integration

DumdSter : Email testing

 

Toutes les applications sur lesquelles nous travaillons ont toujours le besoin d’émettre des mails.
En règle générale, ces mails servent à notifier ou informer des utilisateurs. 
Bien souvent, le contenu du mail est dynamique, ainsi que les paramètres d’envoi tels que l’émetteur, le destinataire, le sujet, etc…
Bien entendu, la gestion des mails est assurée par un composant générique, développé par nos soins ou dans 95% des cas, fourni par un framework tiers (ex: Spring).

Associé à ce coté dynamique, on a des règles métier. Je pense que vous voyez où je veux en venir.
Afin de garantir la cohérence par rapport à ces règles et surtout détecter les régressions en cas d’évolution, il est impératif d’écrire les tests unitaires et d’intégration qui vont bien.

Tester un envoi de mail, n’est pas toujours évident dans le sens où le résultat produit est un mail qu’il faut réussir à intercepter une fois qu’il a été construit et envoyé.

Dumbster est un outil permettant d’adresser ce besoin de manière efficace et très simple.
L‘objectif est de permettre au sein d’un test unitaire/test d’intégration de démarrer un serveur SMTP afin d’intercepter les mails envoyés.
Le fait d’avoir un serveur de ce type à disposition facilite grandement les choses. 

La mise en place sur un projet est d’une simplicité déconcertante. Elle se résume aux étapes suivantes : 
– ajouter la dépendance dans votre pom (ou dans le classpath pour un projet non mavenisé)
– démarrer le serveur smtp au début du test (1 ligne)
– envoyer vos mails
– récupérer vos mails (1 ligne)
– traiter le résultats avec vos assertions
– arrêter le serveur smtp (1 ligne).

Sans exagération, ce n’est pas plus compliqué que cela. Il n’y a aucune configuration à faire.
Plus concrètement, voici un exemple de code mettant en œuvre l’outil. 

SimpleSmtpServer server = SimpleSmtpServer.start();

// envoi des mails

// récupération du nombre de messages reçus par le serveur
int receivedEmailSize = server.getReceivedEmailSize();

// récupération des emails de manière effective
Iterator emails = server.getReceivedEmail();

//traitement des mails reçus

SimpleSmtpServer.stop();

Cela ne nécessite pas plus de travail que cela.

Ce projet va bientôt avoir 10 ans d'existence, la dernière release a été faite en novembre 2005. Il ne semble plus y avoir beaucoup d’activité sur le projet, cependant le service rendu par cet outil est précis et fonctionne bien.

Étant donné l'âge de l’outil, bon nombre d’entre vous connaissent probablement déjà l’outil ; dans ce cas n’hésitez pas à donner vos impressions sur l’outil.

#java #smtp #test #fake #integration

DBUnit

DBunit permet de fournir un contexte de base de données pour vos tests. Bien sûr, il existe des possibilités de mocker les sources de données externes afin de limiter les dépendances ; ceci est valable dans le cadre de tests unitaires. Lorsque l’on passe aux tests d’intégration, il est vraiment intéressant de décrire des cas réels.
C’est là que DBUnit intervient.

Cet outil vous permettra de charger un ensemble de données cohérent dans votre base de données pour lancer vos tests. Une fois les tests terminés, la base de données retrouvera son état initial. L’objectif est de s’assurer qu’à chaque campagne de test, la base de données contienne les données nécessaires pour assurer un contexte d'exécution fiable pour les cas de test.

La création des jeux de tests se fait de 2 manières :
– soit manuellement en écrivant les fichiers xml,
– soit en exportant les données depuis la base vers des fichiers au format xml.

Il s’intègre avec Maven au travers d’un plugin.

Bien que le projet n’ait pas évolué depuis 2010, les fonctionnalités qu’il propose sont vraiment très utiles et ont toutes leur place dans votre boîte à outils.

#java #test #integration #dbunit #db

Créez un site Web ou un blog gratuitement sur WordPress.com.

Retour en haut ↑

Concevoir un site comme celui-ci avec WordPress.com
Commencer