Il existe plusieurs outils de test différents pour PL/SQL. Steven Feuerstein en a écrit deux, utplsql et Testeur de code Quest pour Oracle (anciennement QUTE). Je suis un grand fan d'utplsql, mais il n'a plus de communauté de support active (ce qui est dommage). Il a également tendance à être assez verbeux, en particulier lorsqu'il s'agit de configurer des montages de test. Il a le cardinal virtuel d'être des packages PL/SQL purs; le code source est un peu noueux mais c'est FOSS.
QCTO est livré avec une interface graphique, ce qui signifie - comme les autres produits Quest, c'est-à-dire TOAD - qu'il s'agit de Windows uniquement. Il n'automatise pas exactement la génération de données de test, mais il fournit une interface pour la prendre en charge. De plus, comme les autres produits Quest, QCTO est sous licence bien qu'il existe une copie gratuite.
Steven (divulgation, il est l'un de mes héros Oracle) a écrit une comparaison des fonctionnalités de tous les outils de test PL/SQL. Évidemment, QOTC sort en tête, mais je pense que la comparaison est honnête. Vérifiez.
Conseils sur les appareils de test en utplsql
La gestion des données de test pour les tests unitaires peut être un véritable casse-tête. Malheureusement, utplsql n'offre pas grand-chose pour supporter le fardeau. Alors
- Toujours tester par rapport aux valeurs connues :
- Évitez d'utiliser dbms_random ;
- Essayez de restreindre l'utilisation des séquences aux colonnes dont les valeurs n'ont pas d'importance ;
- Les dates sont également délicates. Évitez de coder en dur les dates :utilisez des variables renseignées avec sysdate. Apprenez à apprécier
add_months(),last_day(),interval,trunc(sysdate, 'MM'), etc.
- Isolez les données de test des autres utilisateurs. Construisez-le à partir de zéro. Utilisez des valeurs distinctives dans la mesure du possible.
- Créez uniquement la quantité de données de test dont vous avez besoin. Les tests volumétriques relèvent d'une autre responsabilité.
- Lorsque vous testez des procédures qui modifient les données, créez des enregistrements spécifiques pour chaque test unitaire.
- Aussi :ne vous fiez pas à la sortie réussie d'un test pour fournir l'entrée d'un autre test.
- Lorsque vous testez des procédures qui rapportent simplement des enregistrements de partage de données entre les tests unitaires, le cas échéant.
- Partagez les données du cadre (par exemple, les clés primaires référencées) dans la mesure du possible.
- Utilisez des champs de texte libre (noms, descriptions, commentaires) pour identifier le ou les tests qui utilisent l'enregistrement.
- Réduire le travail nécessaire à la création de nouveaux enregistrements :
- N'attribuez que les valeurs nécessaires à la suite de tests et aux contraintes de la table ;
- Utilisez autant que possible les valeurs par défaut ;
- Procéduralisez autant que possible.
Autres choses à garder à l'esprit :
- la configuration d'un dispositif de test peut être un exercice chronophage. Si vous avez beaucoup de données, envisagez de créer une procédure pour configurer les données statiques qui peuvent être exécutées une fois par session et n'incluez que les données volatiles dans le
ut_setuplui-même. Ceci est particulièrement utile lors du test de la fonctionnalité en lecture seule. - n'oubliez pas que la création de données de test est un exercice de programmation à part entière, et donc sujette aux bogues.
- utiliser toutes les fonctionnalités d'utplsql.
utAssert.EqQuery,utAssert.EqQueryValue,utAssert.EqTable,utAssert.EqTabCountetutAssert.Eq_RefC_Querysont toutes des fonctionnalités très utiles lorsqu'il s'agit de déduire les valeurs de données volatiles. - lors du diagnostic d'un test qui ne s'est pas déroulé comme prévu, il peut être utile d'avoir les données qui ont été utilisées. Pensez donc à avoir un
ut_teardowncreux procédure et effacer les données de test au début deut_setup.
Gérer le code hérité
Commenter le message de Gary m'a rappelé une autre chose que vous pourriez trouver utile. Steven F a écrit ulplsql en tant qu'implémentation PL/SQL de JUnit, l'avant-garde Java du mouvement Test First. Cependant, les techniques de TDD peuvent également être appliquées à de grandes quantités de code hérité (dans ce contexte, le code hérité est tout ensemble de programmes sans aucun test unitaire).
L'essentiel à garder à l'esprit est que vous n'avez pas à tout mettre sous test unitaire immédiatement. Commencez progressivement. Créez des tests unitaires pour les nouveautés, Testez d'abord . Créez des tests unitaires pour les bits que vous allez modifier avant d'appliquer la modification, afin que vous sachiez qu'ils fonctionnent toujours après avoir effectué la modification.
Il y a beaucoup de réflexion dans ce domaine, mais (inévitablement si honteusement) cela vient principalement des programmeurs OO. Michael Feathers est le principal responsable. Lisez son article Travailler efficacement avec le code hérité . Si vous le trouvez utile, il a ensuite écrit un livre du même nom.
