Bonne gestion des tests

Voyons d'abord quelques bonnes pratiques de gestion des scripts de tests.

Qualité du code

Premier point important à garder à l'esprit, le code des scripts de tests est du code Perl comme les autres. Il n'y a donc pas de raison pour qu'il soit plus mal écrit qu'un autre. En fait, comme c'est typiquement du code que la plupart des personnes n'aiment pas écrire ni relire, il est préférable, encore plus que pour le reste du code, qu'il soit écrit de manière propre, lisible et maintenable. Qu'est-ce que cela signifie ? Que le code devrait dans la mesure du possible être écrit en respectant les règles de bonnes pratiques que vous avez l'habitude d'utiliser, par exemple que le code doit passer avec les strictures activées. Autre conseil, éviter de réinventer les roues qui existent déjà. Cela se traduit par l'utilisation de modules qui fournissent ces roues, modules qui seront justement présentés dans les articles qui suivront celui-ci.

Compartimenter ses tests

Une question qui peut venir à l'esprit est de savoir comment répartir ses tests. Vaut-il mieux les mettre tous dans un seul script ou au contraire les répartir le plus possible ? La réponse est que cela dépend :-)

En particulier, cela dépend du code testé et du nombre de fonctions ou fonctionnalités à tester. S'il ne possède qu'un nombre restreint de fonctions ou un périmètre fonctionnel très délimité, l'ensemble des tests peuvent alors tenir dans un seul script court. Par exemple, le module XSLoader, qui fait partie de la distribution standard de Perl, contient l'ensemble de ses tests fonctionnels dans le script t/XSLoader.t. La raison en est que ce module, dont le rôle est de servir d'interface simplifiée à DynaLoader, le chargeur dynamique de bibliothèques externes, ne fournit qu'une seule fonction, load(). Comme celle-ci ne s'utilise pas de dix manières différentes, on a vite fait de tout tester !

Quand le code à tester comporte un périmètre fonctionnel plus important, la solution la plus pratique est d'écrire un script par fonction, groupe de fonctions, fonctionnalité ou type de données à traiter, suivant les spécificités du code en question. C'est généralement la méthode retenue par beaucoup de développeurs publiant leurs modules sur le CPAN. Regardons quelques exemples plus en détails.

Dans le cas du module Parse::Syslog::Mail, assez simple puisqu'il ne fournit que deux méthodes, les scripts se répartissent les tâches de la manière suivante :

01api.t se contente de vérifier si les méthodes de ce module fonctionnent comme prévu;
03diag.t vérifie les messages d'erreur et d'avertissement que le module peut produire;
10fields.t et 11values.t vérifient que le module analyse correctement des ensembles de données (fournis avec le module); le premier vérifie mécaniquement que les champs ont bien été isolés, le second que les valeurs renvoyées correspondent à ce qui était attendu.

Dans le cas d'un module plus complexe comme Net::Proxy, la suite de tests doit aussi réaliser des tests plus élaborés.

les premiers scripts, de 10proxy_new.t à 14proxy_debug.t se contentent de tester l'API du module, en invoquant le constructeur de différentes manières;
les scripts suivants, en particulier les 30tcp_tcp.t à 33dual.t, sont plus sophistiqués et créent des clients et serveurs réseaux afin de tester les fonctionnalités de proxying proprement dite du module.

Enfin, pour les modules poids lourds comme LWP ou POE, leur suite de tests est suffisamment importante pour que les scripts soient rangés dans des sous-répertoires distincts dans le répertoire t/, nommés en fonction du domaine de fonctionnalités testées. Par exemple, dans le cas de POE, les scripts de test sont classés de manière très hiérarchisée :

le répertoire 10_units/ contient une large suite de tests unitaires permettant de vérifier les fonctionnalités de base, dont les tubes, les filtres et les exceptions;
20_resources/ contient

Pourquoi compter ses tests

Un point qui peut sembler très contraignant à beaucoup de développeurs (il l'est pour l'un des auteurs) est de devoir compter les tests d'un script. Après tout, il est bien plus facile d'utiliser l'option no_plan et de laisser les modules faire le travail de comptage des points de test à notre place. De prime abord, ce point de vue peut sembler raisonnable puisqu'après tout, les programmes sont a priori là pour nous libérer des tâches fastidieuses, et compter le nombre de tests exécutés en fait partie. Et c'est en effet le cas, mais seulement pour les tests exécutés : à tout moment, on peut savoir combien de tests ont été exécutés (que ce soit avec succès ou échec). Mais le script de test n'a aucun moyen de savoir combien de tests restent à exécuter. Cette information ne peut lui être fournit que de l'extérieur, par la personne qui écrit le script.

Test::More

À noter que lorsqu'on parle des fonctionnalités de Test::More, celles-ci sont généralement héritées de Test::Builder qui est le module d'architecture sur lequel il s'appuie, et qu'elles s'appliquent donc en règle générale aux modules qui dérivent eux aussi de Test::Builder.

Le programmeur paresseux va se demander quelle est l'importance de connaître à l'avance le nombre de tests à exécuter. La réponse est qu'il s'agit d'une contrainte de cohérence du script, permettant de vérifier son bon déroulement. La raison technique se trouve dans la description du protocole TAP de l'article précédent. Dans le cas normal, quand le plan est déclaré en début de session, l'interpréteur TAP (dans le cas général, il s'agit de Test::Harness) sait combien de tests doivent être exécutés par le script. Si celui-ci meurt en cours d'exécution, l'interpréteur TAP est donc en mesure de s'en rendre compte car il verra une interruption du flux avant le nombre prévu :

    1..51
    ok 1
    ok 2
    ...
    ok 22
    ok 23

Ici, le script s'arrête après le point 23 alors qu'il aurait dû en exécuter 51. De plus, Test::Harness va recueillir le statut de sortie du script et le décoder pour essayer d'en savoir plus. Test::More par exemple, sort avec comme valeur de statut le nombre de tests qui ont échoué.

On peut trouver là une nouvelle raison de penser qu'il n'y a pas besoin de s'ennuyer avec le comptage des tests puisque en cas d'erreur, Test::More va positionner le statut avec une valeur d'erreur qui sera détectée par Test::Harness. Sauf qu'il y a plusieurs problèmes qui font que ce n'est pas vrai partout, et que cela va de moins en moins le devenir à l'avenir. Car si Test::Harness a actuellement une forte dépendance par rapport au statut de sortie du script de test, cela provient surtout du l'histoire de Perl, qui est un langage né sur Unix. Or Perl est disponible sur un grand nombre de plates-formes, et certains systèmes n'ont pas la même notion de statut de sortie, voire pas de statut du tout. Ce mécanisme fonctionne bien sous Unix, mais il n'est pas garanti ailleurs.

Portabilité

Après tout, cela ne devrait surprendre personne, Perl étant un langage contenant un nombre non négligeable de fonctions n'ayant vraiment de sens que sous Unix, et dont certaines sont très difficiles, voire impossibles à émuler sur des systèmes ne possédant pas de fonctions équivalentes, comme par exemple fork(), chroot(), chmod(), chown(), kill(), link(), les fonctions IPC System V, et d'autres encore.

De plus, deux autres phénomènes tendent à pousser à l'abandon à plus ou moins court terme de l'utilisation du statut comme déterminant primaire du succès ou de l'échec d'un script. Le premier est l'utilisation de Test::Harness pour tester des programmes écrits dans d'autres langages de programmation. Suivant les langages considérés, le positionnement du statut de sortie peut ou non être supporté, et, même quand il l'est, ne pas être positionné pour des raisons culturelles (on peut notamment penser à Java).

Le second est que le flux TAP peut ne pas être généré par un script directement contrôlé par Test::Harness mais provenir d'une source extérieure, par exemple au travers du réseau en utilisant HTTP comme mécanisme de transfert. Il n'y aura alors pas de notion de statut du tout.

Enfin et plus fondamentalement, le statut de retour du script ne fait pas partie de la spécification du protocole TAP. Il s'agit d'une propriété externe au protocole, un artefact qui a été conservé parce qu'il avait son utilité, même s'il avait aussi ses inconvénients. On peut noter d'ailleurs que le positionnement du statut est de plus une spécificité de Test::More, les scripts produisant leur sortie ok / not ok à la main ne le positionnant typiquement pas (sauf quand ils meurent violemment), pas plus que certains scripts basés sur Test, qui peuvent fournir un statut de succès malgré l'échec de certains points de tests.

En résumé, cette contrainte, si elle en est une pour le programmeur, permet aussi de mieux limiter le périmètre d'exécution du script et donc de mieux diagnostiquer les problèmes. Pour compenser, nous allons vous montrer quelques techniques pour aider le comptage des tests.

Techniques de comptages

Un premier moyen simple est d'utiliser no_plan...

Oui, on vient de vous dire qu'il ne fallait pas l'utiliser, mais calmez-vous et écoutez plutôt la suite de l'explication :-)

Un premier moyen simple, donc, est d'utiliser no_plan pendant la phase d'écriture du script, puis, une fois que celui-ci est en grande partie écrit, il suffit de l'exécuter de manière verbeuse avec prove -bv t/script.t par exemple, et de relever le nombre total de tests exécutés. Il suffit alors de positionner votre plan à cette valeur. Par la suite, il suffira de l'incrémenter lors de l'ajout d'autres points de tests.

Pour les scripts de tests s'appuyant sur des données dont la quantité peut varier ou être paramétrée, une bonne technique consiste justement à déterminer le nombre de tests par donnée analysée. Il suffit ensuite de calculer le nombre total de tests par une simple multiplication (et éventuellement l'addition des tests non dépendants des données). Ainsi la plupart des scripts de test du module Net::Pcap commencent de la manière suivante :

    my $total = 10;  # number of packets to process
    plan tests => $total * 19 + 5;

Plusieurs des scripts sont en effet orientés autour de la capture de paquets réseau (ce qui n'est pas une surprise puisque c'est le rôle de Net::Pcap), sur lesquels sont effectués plusieurs tests de cohérence, dans cet exemple 19 par paquet. Si les tests portent sur des données spécifiques, il suffit de le stocker dans un endroit facilement accessible et de compter la quantité de données avant la déclaration du plan. « L'endroit » peut être par exemple une chaîne, un tableau, un hash ou dans la partie DATA du script. Une bonne illustration de cette méthode est donnée dans les scripts du module Pod::POM::View::HTML::Filter :

    my @tests = map { [ split /^---.*?^/ms ] } split /^===.*?^/ms, << 'TESTS';
    =begin filter foo

    bar foo bar
    baz

    =end
    ---
    <html><body bgcolor="#ffffff">
    <p>bar bar bar
    baz</p>
    </body></html>
    ===
    ...
    ===
    =begin filter verb

        verbatim block

    verbatim textblock

    =end
    ---
    <html><body bgcolor="#ffffff">
    <pre>    verbatim block</pre>
    <pre>verbatim textblock</pre>
    </body></html>
    TESTS

    plan tests => scalar @tests + 2;

Ici, les données sont stockées sous forme d'enregistrements séparés par des ===, chaque enregistrement étant lui-même constitué de deux parties séparées par des ---. La première partie correspond à des fragments de documents Pod, la seconde au résultat attendu de la conversion du fragment par le module testé, Pod::POM::View::HTML::Filter[1].

Perl Best Practices

Comme le titre l'indique, Damian Conway a rassemblé dans ce livre 256 règles de bonnes pratiques d'écriture de code Perl, basées sur sa propre expérience ainsi que de celle d'autres grands programmeurs Perl. Ces règles permettent, si on les suit, d'écrire un code qui sera lisible pour un maximum de personnes, facilitant ainsi d'autant sa maintenabilité. À peu près tous les sujets qu'un programmeur Perl pourrait rencontrer son traités, des boucles et structures de contrôles aux hiérarchies de classes et d'objets, en passant par la gestion des entrées-sorties, des erreurs, des options en ligne de commande, ainsi que les meilleures manières d'écrire et d'utiliser les fonctions, les expressions régulière et la documentation.

Il propose aussi d'un chapitre consacré aux tests, conseillant de ne pas hésiter à utiliser Test::More et consorts dès que possible, par exemple pour transformer en script de test tout bug applicatif rapporté.

Écrivant avec son humour habituel, Damian explique en détail le pourquoi de chaque règle. Ainsi, même si on n'est pas de prime abord d'accord avec ses choix, il est très intéressant de lire ses explications, qui décrivent en quoi cela peut sinon nuire à la lisibilité et à la compréhension du code.

On ne peut résister à l'envie de vous citer la première et probablement l'une des plus importante règles données par Damian :

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

Disponible en français sous le titre De l'art de programmer en Perl.

Un autre exemple de cette technique est donné dans le script de test principal du module File::Read :

    my @one_result_tests = (
        ...
        {
            args     => [ File::Spec->catfile(qw(t samples pi)) ], 
            expected => "3.14159265358979\n", 
        }, 
        {
            args     => [ File::Spec->catfile(qw(t samples hello)) ], 
            expected => 'Hello', 
        }, 
        {
            args     => [ File::Spec->catfile(qw(t samples world)) ], 
            expected => "world\n",
        }, 
        ...
    );

Le concept est exactement le même, sauf que les données sources et les résultats attendus sont stockés dans une structure Perl, réduisant ainsi le comptage des tests à quelques multiplications et additions triviales :

    plan tests => 5 + @one_result_tests * 2 + ...

Enfin, une dernière technique, utilisée par Jérôme Quelin, permet de simplifier encore le comptage. Elle consiste à utiliser des blocs BEGIN pour effectuer le compte, bloc par bloc, au fur et à mesure de la compilation du script :

    use strict;
    use Test::More;
    my $tests;              # nombre total de tests
    plan tests => $tests;   # déclaration du plan

    BEGIN { $tests += 4 }   # tests du chargement et de l'API
    use_ok('WebBrowser');
    can_ok('WebBrowser', qw(new clone load save));
    my $browser = WebBrowser->new
    isa_ok($browser, 'WebBrowser');
    can_ok($browser, qw(clone load save));

    BEGIN { $tests += 5 }   # tests de la méthode load()
    my $test_page = 'test.html';
    eval { $browser->load($test_page) };
    is( $@, '', "méthode load(), argument : $test_page" );
    ok( $browser->status_ok, "page correctement chargée" );
    is( $browser->current_page->location, $test_page );
    is( $browser->current_page->size, -s $test_page );
    like( $browser->current_page->title, '/Page de test/' );

L'astuce est que les blocs BEGIN sont exécutés dès la phase de compilation du script. Comme la variable $tests a tout de même été déclarée au début du script (3e ligne), elle est déjà allouée et connue. Les blocs BEGIN incrémentent ensuite sa valeur au fur et à mesure de la compilation du script. Lorsque celui-ci est finalement exécuté, la variable $tests contient donc le nombre total de tests, qui est donné comme plan.

Écriture par paragraphe

Recommandée par Damian Conway dans Perl Best Pratices[3], ce mode d'écriture consiste à séparer le code en petits ensembles de lignes, plus faciles à digérer qu'un gros bloc.

Cette technique est particulièrement bien adaptée pour les scripts de tests nécessitant d'être un peu long. Elle se marie de plus à merveille avec l'écriture par paragraphe et permet ainsi de simplifier d'autant la maintenance du programme : le compte des tests effectués se faisant localement à chaque paragraphe, cela limite les possibilités de se tromper.

À noter que le conseil de la section précédente de bien compartimenter les tests dans des scripts séparés prend maintenant tout son sens. L'autre avantage de la compartimentation est que cela limite le nombre de tests par script, facilitant par la-même leur décompte, quelle que soit la technique retenue.

Tests et Perl - Bonnes pratiques

Chapeau de l'article

Bonne gestion des tests

Qualité du code

Compartimenter ses tests

Pourquoi compter ses tests

Techniques de comptages

Intégration au cœur du processus

Phase de développement

Phase de déploiement

Sélection des tests

Conclusion

Références

Auteurs