Posts Tagged ‘Test’

Unit-testing is the way to go in modern programing. When you’re at writing unit tests, chances are that you will eventually need the so-called mock objects.

You can find a pretty good definition of Mock objects here. In Perl, writing Mocks can be done with Test::MockClass and Test::MockObject which are pretty complete modules for that purpose.

However, I’ve came to gugod’s blog and found out his post about Mocking in Perl. I like his post and find his conclusion pertinent:

However, I still want my test program reads as simple as the rspec statement, it reads better. The most important of all, you don’t really need to know the whole pros and cons and the concept of “Mocking” to do it.

Hence I’ve been thinking at a module who could be named Test::Mocker – or even Test::EasyMocker – and who will be usable like the following.

use Test::Mocker 'Player';

Player->should( run => 42);

We could also imagine a more complex mock with a sub instead of a constant value:

use Test::Mocker 'Player';

Player->should( run => sub { return 42; });

As you can see, when importing Test::Mocker, we give it a list of packages we intend to mock in the test, that provides them with the “should” static method.

I like the ease of use of that syntax and find it pretty natural to write; I’d be happy to read your comments on this.

Comme expliqué ici, Test::WWW::Mecanize::Runner est publié.

Après avoir fouillé un peu pour voir ce qui se fait en matière de tests fonctionnels pour les applications Web, je suis tombé sur la combo qui tue :

• WWW::Mechanize pour scripter un surf
• HTTP::Recorder pour enregistrer un scénario en live au format WWW::Mechanize (via un proxy local)
• Mozilla::Mechanize pour jouer le script WWW::Mechanize en pilotant Mozilla (via xulrunner)
• Win32::IE::Mechanize pour faire de même avec IE en environnement Win32.

Il manquait à mon gout juste une chose : un wrapper qui vous permette d’écrire un scénario sans se soucier de l’agent à utiliser (WWW, Mozilla ou IE). En effet, ça serait vraiment dommage d’avoir à écrire autant de scénario qu’on a d’environnement à tester.

J’ai donc écrit un petit wrapper pour écrire une suite de test qui joue un scénario avec l’agent que l’on souhaite.

Globalement ça marche comme ça :

1. on écrit le scéario qui nous plait dans un module qui hérite de Test::WWW::Mechanize::Runner dans des “suites”

   package MonScenario;
   use Test::WWW::Mechanize::Runner;
   use base 'Test::WWW::Mechanize::Runner';
   
   suite load_google => sub {
       my ($agent) = @_;
   
       ok($agent->get('http://www.google.fr'),
           'GET http://www.google.fr');
   };
   

2. le fichier de test ne comprend que 3 lignes et ressemble à ça (pour un jeu avec Mozilla::Mechanize) :

   use MonScenario;
   MonScenario->init('mozilla');
   MonScenario->run();
   

Bientôt sur le CPAN…

PS : bon, il y a un soucis de compilation pour Mozilla::DOM (une dépendance de Mozilla::Mechanize) sur Debian (il cherche à utiliser le xpcom de mozilla alors que debian oblige à passer par xulrunner) ; le patch est simple, je compte le soumettre dans le BTS du CPAN je l’ai soumis sur le BTS du module, et si je trouve une demi-heure quelque part, à packager libmozilla-mechanize-perl.