Comment fonctionne les tests en Perl : quels modules de test intégrés et tiers existent, comment diffèrent-ils, et quelles pratiques de test sont largement utilisées dans les projets Perl ?

Réponse

En Perl, un ensemble traditionnel de modules de test est utilisé : Test::Simple, Test::More, ainsi que des frameworks complexes comme Test::Class, Test::Most. Le module de base est Test::More — il fournit un ensemble riche de fonctions : vérifications d'égalité, comparaisons de structures, tests d'exceptions, etc.

Classification des modules populaires :

• Test::Simple — pour des tests simples et élémentaires ;
• Test::More — le standard de facto pour la plupart des projets ;
• Test::Exception, Test::Deep, Test::Warn — pour vérifier des aspects supplémentaires (exceptions, structures imbriquées, avertissements) ;
• Test::Class, Test::Class::Moose — approches orientées objet.

Exemple de test avec Test::More :

use Test::More tests => 2;

is(2 + 2, 4, 'La somme fonctionne');
like('foo_bar', qr/foo/, 'Il y a foo');

Meilleures pratiques :

• Tous les modules publics doivent avoir des tests automatiques dans le répertoire t/.
• Ne pas mélanger les données de test avec le code de production.
• Appliquer des tests unitaires, d'intégration, et parfois des tests basés sur des propriétés.

Question piège

Peut-on écrire ses propres tests en Perl sans utiliser les modules Test::*, juste en utilisant les constructions die/print ? Quels sont les risques associés à cette approche ?

Réponse : Formellement oui — on peut écrire ses "tests" en utilisant print et die pour afficher le résultat. Cependant, dans ce cas, on ne forme pas une approche correcte d'automatisation : il n'y a pas de support pour les intégrations TAP/CPAN, il est difficile de créer des rapports et d'analyser de nombreux tests, la mise à l'échelle et le support de la base de tests sont compliqués.

Exemple de test échoué :

print 'Multiplication ok
' if multi(2,3) == 6;
die 'ÉCHEC' if multi(2,0) != 0;

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet

---

Histoire

Dans un ancien projet, les tests étaient écrits "manuellement" via die et print. Il était impossible d’intégrer automatiquement la construction de modules CPAN — les scripts ne renvoyaient pas de statuts clairs, ce qui faisait que les erreurs de test étaient négligées dans les versions.

---

Histoire

La tentative de mélanger l'utilisation de Test::Simple et Test::More sans tenir compte de la structure TAP (Test Anything Protocol) a entraîné une violation de la sortie de la système de test automatique. Une refonte de l'infrastructure de test a été nécessaire.

---

Histoire

L'absence d'une bonne couverture de tests Test::Exception a été la cause de plusieurs erreurs dans le traitement des données d'entrée : un des modules lançait incorrectement des exceptions, ce qui n'a pas été détecté lors des tests, et le bug a été mis en production.