Fiche de révision Vérifications

Principes et utilité des tests

Vérifier un programme nécessite de multiples tests pour en contrôler les différentes parties.
Le test unitaire permet d’évaluer une portion réduite de code. Il s’assure que le code produit le résultat attendu.

Dans la démarche la plus élémentaire, on introduit des tests conditionnels dans le code pour tenter de traiter certains problèmes.
Si l’utilisateur de la fonction introduit des données insensées, elle dysfonctionne. Ainsi, notre fonction déclenche une erreur.
Pour y remédier, il faut introduire un test conditionnel préalable au calcul.
Mais le message d’erreur sera accessible à l’utilisateur sur le même plan que les affichages du programme dans son fonctionnement normal.
On peut vite se retrouver avec des problèmes en cascade et des erreurs dont les conséquences pourraient apparaitre loin de leur origine.

Le mot-clé assert permet de vérifier si une condition est vraie, et de générer une erreur si la condition n’est pas remplie.
Si nous introduisons une valeur erronée en argument pour le paramètre utilisé, une AssertionError survient et le programme s’arrête.
Le mécanisme d’assertion ne se déclenche pas si le programme n’est pas exécuté en mode debug car l’instruction assert est alors ignorée.
Il faut donc privilégier l’assertion à des fins de mise au point d’un programme uniquement.
Le mot-clé raise nous permet de lever une exception.

Nous pouvons programmer nos tests dans un fichier séparé qui aura accès à notre fonction pour l’évaluer. Ce fichier peut par ailleurs comporter d’autres fonctions et un code les mettant en œuvre.
Puis créons un autre programme, destiné à effectuer différents tests unitaires, situé dans le même répertoire que le fichier séparé.
Les tests doivent être aussi indépendants que possible du code.
Notre programme de tests constitue un ensemble de vérifications également appelé jeu de tests.
Il existe des bibliothèques spécialisées capables de vérifier des jeux de tests complets sans s’arrêter à la première erreur.

L’un des intérêts des tests unitaires est de nous protéger contre des régressions.
Cela peut notamment se produire lors de la réécriture du code, parfois appelée réusinage.

Malgré les précautions et contrôles apportés par les tests, des défauts de conception et des erreurs logiques présents dans le code peuvent passer inaperçus.
Dans l’approche classique de développement, les tests sont écrits après le code et en fonction du code.

Le « Test Driven Development » (TDD) consiste en un développement informatique piloté par les tests.
Dans cette approche du développement, on ne commence pas par écrire le code du programme mais celui d’un test du code à venir.
Le développement est incrémental : chaque test précise le comportement désiré de notre programme.