> Data > Testez par unités vos procédures stockées

Testez par unités vos procédures stockées

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Dan Sawyer - Mis en ligne le 21/01/2004

Mettez en forme votre code de procédure

Imaginez ceci : vous venez juste de finir le débogage de la dernière procédure stockée pour la dernière application SQL Server du département. Etes-vous satisfait de votre travail ? Etesvous certain que votre code T-SQL sera à  la hauteur des attentes des utilisateurs ? Quid des fonctionnalités que vous avez placées dans le code ? ...

Imaginez ceci : vous venez juste de finir le débogage de la dernière procédure stockée pour la dernière application SQL Server du département. Etes-vous satisfait de votre travail ? Etesvous certain que votre code T-SQL sera à  la hauteur des attentes des utilisateurs ? Quid des fonctionnalités que vous avez placées dans le code ? Avezvous couvert tous les aspects de la gestion ? Chaque fonction tient-elle ses promesses comme prévu dans tous les scénarios d'exploitation normaux?

Même si vous pouvez répondre par oui à  toutes ces questions, le moment de relâcher votre effort n'est pas encore venu. Qu'en est-il des suites possibles ? Avez-vous testé les conditions d'erreur courantes qui ont causé des problèmes par le passé ? Et qu'en est-il des gestionnaires d'erreurs ? Sont-ils eux-mêmes impeccables ? Si vous vous sentez faiblards dans l'un de ces domaines, il vaut peut-être mieux réévaluer la manière dont vos procédures stockées sont testées par unités.
Contrairement aux tests système que les testeurs professionnels effectuent après qu'une application ait été entièrement codée, le test par unités recherche les erreurs dans des modules individuels, comme les procédures stockées, tout au long du développement de ces modules. Le test par unités n'est pas difficile mais, pour être efficace, il exige du planning, de la documentation et, par-dessus tout, une compréhension partagée de certains principes de base. Donc, avant de plonger dans le processus de test, commençons par dissiper quelques préjugés courants sur le test par unités, qui nuisent souvent à  son efficacité.

Préjugé 1.
Tester et déboguer
c’est du pareil au même. Le test recherche
les erreurs et signale leur manifestation.
Le débogage essaie de
trouver la cause de l’erreur puis corrige
le code défectueux.

Préjugé 2.
Le test sert à  montrer
qu’un programme est sans erreur. Le
but du test devrait être de trouver les
erreurs, pas de prouver leur inexistence.

Préjugé 3.
Tester est affaire de
professionnels. Le test doit se faire par
étapes et doit impliquer des programmeurs
et des testeurs professionnels.
La première étape, le test par unités,
incombe aux programmeurs. Une fois
que votre code a été soumis aux tests
par unités, il est prêt à  subir le test système
par un professionnel du contrôle
de qualité.

Préjugé 4.
Tester est une tâche
qui intervient en fin de code. L’idéal est
de planifier la manière de tester
chaque fragment de code que vous
écrivez. La conception des tests doit
venir avant le coding, pas après.

Préjugé 5.
Les procédures stockées
n’ont pas besoin de test formel.
Pour certains DBA (Database Administrators),
le test consiste à  balancer
quelques valeurs de paramètres dans
une procédure et à  crier victoire quand
la requête s’exécute correctement.
Malheureusement, de tels tests improvisés
sont difficiles à  déboguer, ne sont
pas réutilisables et font perdre du
temps. Le test formel exige de la
discipline, mais c’est le prix de la vraie
fiabilité.

Téléchargez cette ressource

Microsoft 365 : HP Subscription Management Services en détail

Microsoft 365 : HP Subscription Management Services en détail

Collaboration à distance, environnements de travail et productivité optimisés, gestion évolutive des licences, accélérez la transformation de votre business pour le faire entrer dans l’ère de la collaboration hybride. Découvrez comment le service de gestion des abonnements HP peut vous aider à optimiser vos investissements et votre stratégie de gestion de vos abonnements Microsoft 365.

Data - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT