Une autre astuce courante pour les scripts de tests unitaires est d'envelopper le corps de leur code dans un bloc « appelant »:
#!/usr/bin/perl
use strict;
use warnings;
unless (caller) {
# startup code
}
sub foo { ... }
Lorsqu'il est exécuté à partir de la ligne de commande, Cron, un script bash, etc., il fonctionne normalement. Cependant, si vous le chargez à partir d'un autre programme Perl, le code "unless (caller) {...}" ne s'exécute pas. Ensuite, dans votre programme de test, déclarez un espace de noms (puisque le script exécute probablement le code dans le paquet principal :) et «faites» le script.
#!/usr/bin/perl
package Tests::Script; # avoid the Test:: namespace to avoid conflicts
# with testing modules
use strict;
use warnings;
do 'some_script' or die "Cannot (do 'some_script'): $!";
# write your tests
'faire' est plus efficace qu'éval et assez propre pour cela.
Une autre astuce pour tester les scripts consiste à utiliser Expect. C'est plus propre, mais il est également plus difficile à utiliser et il ne vous laissera rien remplacer dans le script si vous avez besoin de se moquer de quelque chose.
S'il y a une possibilité à distance que quelqu'un empaquette votre script avec PAR (ie "pp -o binary script.pl; ./binary") ou l'évalue réellement et s'attende à ce qu'il s'exécute, alors * s'il vous plaît * ne le faites pas . Cela m'a donné beaucoup de soucis avec perlcritic quand je préparais mon discours YAPC :: EU. – tsee
Pour être juste, je ne m'inquiète pas au sujet de PAR. Perl 5 a trop de défauts pour que je me souvienne de tous les cas spéciaux, en particulier pour le code non-core :( – Ovid
@tsee sur quelle fin est votre préoccupation sur? Écrire des scripts dans un bloc 'à moins appelant 'ou exécuter le test par' – ajwood