Utilisateurs de Perl à Paris

YAPC::Europe 2002 - Jour 1

Un historique de toutes nos réunions


Table des matières

[ La voix de BooK ]

La première journée est traditionnellement celle des tutoriels.

Matin

J'ai un peu zoné entre les tutoriels de Tom Phoenix (Practical Web Programming), de Redverd Davis (Developping GUI applictions with Gtk.pm) et Mark Overmeer (E-Mail processing with Perl). Mais finalement, j'ai principalement testé le Wi-Fi.

Stéphane a été suivre le tutoriel Gtk, pour pouvoir comparer les différents toolkits disponibles pour Perl (bien sûr que c'est pour TeXmacs !).

Après-midi

Bon, je vais essayer de faire des comptes-rendus dignes de ceux de Michel Rodriguez pour TPC 6...

Advanced Testing, par Michael Schwern

Peu de temps avant cette conférence, la grande question était se savoir si Schwern y serait... En effet, il devait arriver le jour même en Allemagne.

La conférence commence, Michael est là, tout va bien !

Il commence sans micro, dans une salle assez grande :

La présentation commence par des questions (du public).

Comment tester une connexion à une base de données sans base de données, ou plutôt comment tester que cela ne marche pas :

{
    local *DBI::connect = sub { return 0 }
    # ... tests here ...
}

ou même avec des arguments

{
    my @args
	local *DBI::connect = sub {
        @args = @_;
        return 0;
	}

    # ... tests here ...

    is( $args[0], 'DBI');
    is( $args[1], $driver_string);
}

Comment tester une application web ? (J'ai pas compris la réponse, sinon qu'elle est en deux parties, et que Schwern a une réponse pour la première et un projet pour la seconde.)

La conférence à proprement parler commence :

Comment tester du HTML ?

Les regex ne suffisent pas. Il faut tester la fonctionnalité du HTML  est-ce qu'il affiche un lien vers tel autre site, est-ce que le HTML généré est conforme, etc.

Avec WWW::Automate, on peut construire un "mockup browser" (un navigateur bidon). (Note de BooK : en fait, de nos jours, c'est plutôt WWW::Mechanize qu'il vaut mieux utiliser : il part de WWW::Automate, mais ajoute de nouvelles fonctionnalités, et est maintenu par son auteur.)

Le projet de Schwern, c'est Test::HTML. Il devrait permettre de faire des tests logiques, et de répondre à des questions comme :

Et bien sûr, la question qui tue : Any volunteers?

Il faut convaincre vos collaborateurs de faire des tests :

Utilisez Test::Simple, lisez Test::Tutorial... Écrivez vos propres wrappers autour de make test (un petit script quicktest, par exemple)

Les divers types de tests : acceptance, regression, unit, functional... C'est toujours la même chose, mais pas au même moment.

On utilise les mêmes techniques pour tous ces types de tests.

Faire des tests sur des données construites au hasard, puis reproduire le bug. Facile, une fois qu'une erreur est trouvée, vérifier la graine (seed) du générateur de nombres pseudo-aléatoires, et s'en resservir pour regénérer ce type de donnée qui plante. Ensuite, il suffit de les inclure dans le jeu de tests.

OK, j'ai pas tout suivi, mais c'est parce que je préparais mes lightning talks.

Utilisez diag() pour afficher des messages :

# tout comme vous écrivez
open $file or die "horribly";

# utilisez
ok( $opened ) or diag( "oh my god, it's horrible" )

Pour remplacer une fonction de perl, on peut faire :

BEGIN {
   # à partir de 5.6 ?
   *CORE::GLOBAL::open = sub { ... }
}

Il montre l'exemple avec son module Dunce::Files (issu de la distribution Dunce)... Celui-ci prévient quand on ne fait pas de open or die, si on utilise chop au lieu de chomp, etc.

Il montre son code, et on s'apercoit qu'il utilise Function::Override et que justement, open() est... NOT YET IMPLEMENTED ! (rires)

Greg McCarroll fait remarquer que dbmopen() a un message d'erreur qui parle de chmod() ! (rires)

D'ailleurs Greg McCarroll remplace Schwern pour faire un mini-talk sur Test::MockObject.

Test::MockObject

Greg commence en disant : «You've lost the mike!». (rires)

Test::MockObject vous permet d'être paresseux (lazy) avec les tests. En effet, il vous permet de tester du code qui interagit avec des modules pas (encore) écrits.

Pour ce faire, il possède deux méthodes : new() et mock().

my $mail = Test::MockObject->new();
$mail->mock( from => sub { 'a@b.com' } )
$mail->mock( to => sub {} )

Il a d'autres méthodes encore :

Et peut donner des informations sur les appels des méthodes :

Ce qu'il ne fait pas :

Test::MockObject s'appuie sur une idée Java.

Testing web applications

Schwern revient... mais est remplacé par Marty.

Pour tester des application web, vous pourriez utiliser WWW::Automate (remplacé par WWW::Mechanize), qui attaque le site web. Mais cela nécessite d'installer du code dans le chemin de recherche de perl, de relancer Apache...

Solution : plusieurs Apache

Mock::Apache : s'appuie sur Apache::FakeRequest, de CPAN. - behaves like apache::request, but doesnet need apache test first programmin (tfp) -inspired by XP your test is your fucntionnal documentation (use mockobject to test) definin the interface is easier than coding it work is done when the test pass and,... test don't have to be done later!

Schwern revient...

procrastination
+ write test before code (new features)
+ write test asa receiver bug report
- to release with failing test

=> contradiction : how do i test non existing code
use todo()


parle de class::contract


PAUSE

J'ai discuté avec Sec de l'avenir (ou plutôt de l'absence d'avenir)
de Games::Golf.

Class:contract suite

-> class construction module
- design by contract
- give complete privacy

Tests pour le HTML

Test::Builder

in the begining : Test.pm
not widely used

Test::More
people still used wrappers around but that screwed diagnostics and
error line report
- people customizing Test::More

Test::Simple and Test::More are wrappers around Test::Builder


le code de Trest::Simple (basé sur Test::Builder) fait 15 lignes !


Test::Builder a besoin d'utilisateuirs !!
pour ajouter d'autres librairies de test
HTML, networking, events, GUI, databases, and more!


conseiles pour les tests :
test are code, so they can have bugs
- make short tests
- small & focused

test for testing tests

1) write the tests
2) make sure it fails
3) correct the bug or implement the feature


use Test::Harness to test other languages
just have to print ok 1, ok 2...

ca ne marche pas encore bien, mais on y travaille

autre possibilité : Inline::Language
ex: Inline::C pour charger une lib
    et tester les fonctions comme du code Perl

HTML 5 - CSS v3 Mongueurs de Paris, le 4 juillet 2018 Copyright © The Paris Perl Mongers, 1999-2024