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
Guide de technologie 5G pour l’entreprise
Pourquoi la 5G est-elle faite pour votre entreprise ? La 5G peut améliorer la vitesse, la fiabilité et la capacité de votre réseau, permettant ainsi une meilleure collaboration, une productivité accrue et une prise de décision plus rapide. Notre livre blanc " The Big Book of Enterprise 5G" vous fournit les informations stratégiques dont vous avez besoin pour prendre des décisions éclairées et préparer votre entreprise à prospérer dans l'ère de la 5G. Cradlepoint, part of Ericsson est le leader mondial des solutions de réseau sans fil 4G LTE et 5G fournies via le cloud. Connectez vos employés, lieux et objets avec la 4G LTE et la 5G pour un WAN sans fil d'entreprise.
