Discussion :

[Jasmine80]

Bonjour,

J'utilise BioPerl afin de me connecter à Genbank, y reprendre des informations et les charger en base de données MySQL. Je manipule aussi des fichiers textes, fasta et msf et j'utilise ClustalW.
J'aimerais savoir quels tests devrais-je utiliser afin d'améliorer mes scripts? J'ai vu sur le CPAN qu'il existe énormément de modules de test. Pourriez-vous me conseiller sur lesquels utiliser afin de bien contrôler mes scripts? Je ne génère aucun fichier log, je laisse les warnings apparaitre à l'écran (j'utilise les modules strict et warnings). Comment pourrais-je bien surveiller mes programmes?

http://search.cpan.org/search?query=test&mode=all


Merci,



Jasmine,

[Jedai]

Je pense que tu confonds deux choses : les tests qui vérifie qu'une librairie fait bien ce qu'elle dit faire et la surveillance d'une application en production, qui passe par un log.
Tu sembles plutôt avoir besoin du second, pour lequel de bons modules ont été écrit, comme Log::Log4Perl.

--
Jedaï

[Jasmine80]

Oui, je suis perdue, j'ai du mal avec ces deux notions.
J'utilise aussi le module carp

les tests qui vérifie qu'une librairie fait bien ce qu'elle dit

Ca c'est donc le use warnings

la surveillance d'une application en production, qui passe par un log

donc Log::Log4Perl comme tu me le conseil.

Je vais me renseigner au sujet de Log::Log4Perl

Quand un script Perl tourne, n'y a t'il pas automatiquement des fichiers de surveillance créer en cas de plantage?


Merci,

Jasmine,

[Jedai]

les tests qui vérifie qu'une librairie fait bien ce qu'elle dit

Ca c'est donc le use warnings

Non, ce sont les modules Test::* . Il s'agit de l'utilisation de tests unitaire pour vérifier pour chaque fonction de ta librairie si elle fait bien ce qu'elle doit. Tous les modules du CPAN viennent accompagnés d'une suite de test qui est lancé avant l'installation pour vérifier que le module fonctionnera correctement sur ta machine.
Les tests sont dans le répertoire t/, tu peux leur jeter un coup d'oeil pour t'éclairer les idées. Typiquement ils sont bourrés de code comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
{
    # check that generation works properly
    my $dt = DateTime->new( year => 2200,
                            month => 11,
                            day => 3,
                            time_zone => 'UTC',
                          );
    is( $tz->offset_for_datetime($dt), -21600, 'generated offset should be -21600' );
    is( $tz->short_name_for_datetime($dt), 'CST', 'generated name should be CST' );
}

(tiré de la suite de test de DateTime::TimeZone t/02basic.t)

--
Jedaï

[Jedai]

J'utilise aussi le module carp

Carp est très bien, son rôle est surtout d'aider les auteurs de modules à produire des messages d'erreurs intéressant. En effet avec un simple die() l'erreur est reporté comme étant à l'emplacement du die(), donc dans le module, alors qu'on veut souvent reporter une erreur à l'usage d'une des fonctions du module. Dans ce cas l'erreur ne se trouve pas dans le module, mais à l'endroit où la fonction du module a été appelée, c'est à dire dans le script utilisateur, et carp() permet de reporter l'erreur à cet endroit là.

--
Jedaï

[Jedai]

Quand un script Perl tourne, n'y a t'il pas automatiquement des fichiers de surveillance créer en cas de plantage?

Non, pas automatiquement, une méthode de log minimaliste pourrait constituer à rouvrir STDERR vers un fichier, et dans ce cas ce log conservera la trace des warnings et des die() du programme.

--
Jedaï