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é.
