Programmation PYTHON - Zenk - Security - Repository

388
Techniques avancées
QUATRIÈME PARTIE
À quoi servent les tests ?
Dans le cycle de création d’un logiciel, il arrive inévitablement qu’un programmeur
teste le code qu’il a écrit, pour vérifier qu’il se comporte comme prévu. Ces tests sont
préférablement effectués avant de livrer le logiciel ou la fonctionnalité, et font partie
intégrante du travail de développement.
Tester un logiciel comme le ferait le client, pour valider point par point que tout
fonctionne peut devenir relativement fastidieux, car il faut en toute logique recommencer
à chaque insertion ou modification de code.
La première idée de la programmation dirigée par les tests est donc d’écrire des
scripts de tests pour automatiser cette tâche.
La deuxième idée qui en découle est de se prémunir de toute régression. La régression
est le fait d’introduire ou de modifier du code pour ajouter une fonctionnalité A
et de provoquer indirectement un dysfonctionnement dans une fonctionnalité B qui
se comportait jusqu’alors très bien : si la batterie de tests contient un test qui vérifie la
fonctionnalité B et si les tests sont relancés au moment de l’introduction de A, le
problème sera alors tout de suite décelé.
Ce principe est d’autant plus important que le logiciel grossit : il est de plus en plus
difficile pour un développeur d’avoir une vision globale au moment de l’introduction
d’une nouvelle fonctionnalité, pour éviter ces effets de bords.
La programmation dirigée par les tests consiste à écrire des scripts de tests en parallèle
et au même moment que le code, pour chaque nouvelle fonctionnalité introduite
dans le programme.
Enfin, l’action même d’écrire un test au moment de la conception d’une fonctionnalité
augmente de manière considérable la qualité du code : réfléchir à un test valide la
pertinence des paramètres d’entrée, de sortie et le fonctionnement logique du code et
force à une relecture avec plus de recul. Le nombre de bogues ou de défauts de conception
est divisé par cinq par cette action. En outre, ces tests constituent la
meilleure documentation possible pour le code.
Barrière culturelle
« Écrire un test à chaque nouvelle fonction ? Je n’ai pas le temps ! »
Le seul frein réel à ce type d’approche est culturel : il est très difficile pour un développeur
et/ou son chef de projet d’admettre que 60 % du temps de développement
est voué habituellement à déboguer du code écrit. Il est même fréquent, pour ne pas