Documentation SimpleTest : les objets fantaisie partiels

+ +

+ Un objet fantaisie partiel n'est ni plus ni moins + qu'un modèle de conception pour soulager un problème spécifique + du test avec des objets fantaisie, celui de placer + des objets fantaisie dans des coins serrés. + Il s'agit d'un outil assez limité et peut-être même + une idée pas si bonne que ça. Elle est incluse dans SimpleTest + pour la simple raison que je l'ai trouvée utile + à plus d'une occasion et qu'elle m'a épargnée + pas mal de travail dans ces moments-là. +

+ +

Le problème de l'injection dans un objet fantaisie

+ Quand un objet en utilise un autre il est très simple + d'y faire circuler une version fantaisie déjà prête + avec ses attentes. Les choses deviennent un peu plus délicates + si un objet en crée un autre et que le créateur est celui + que l'on souhaite tester. Cela revient à dire que l'objet + créé devrait être une fantaisie, mais nous pouvons + difficilement dire à notre classe sous test de créer + un objet fantaisie plutôt qu'un "vrai" objet. + La classe testée ne sait même pas qu'elle travaille dans un environnement de test. +

+ Par exemple, supposons que nous sommes en train + de construire un client telnet et qu'il a besoin + de créer une socket réseau pour envoyer ses messages. + La méthode de connexion pourrait ressemble à quelque chose comme... +

+<?php
+require_once('socket.php');
+
+class Telnet {
+    ...
+    function &connect($ip, $port, $username, $password) {
+        $socket = &new Socket($ip, $port);
+        $socket->read( ... );
+        ...
+    }
+}
+?>
+

+ Nous voudrions vraiment avoir une version fantaisie + de l'objet socket, que pouvons nous faire ? +

+ La première solution est de passer la socket en + tant que paramètre, ce qui force la création + au niveau inférieur. Charger le client de cette tâche + est effectivement une bonne approche si c'est possible + et devrait conduire à un remaniement -- de la création + à partir de l'action. En fait, c'est là une des manières + avec lesquels tester en s'appuyant sur des objets fantaisie + vous force à coder des solutions plus resserrées sur leur objectif. + Ils améliorent votre programmation. +

+ Voici ce que ça devrait être... +

+<?php
+require_once('socket.php');
+
+class Telnet {
+    ...
+    function &connect(&$socket, $username, $password) {
+        $socket->read( ... );
+        ...
+    }
+}
+?>
+

+ Sous-entendu, votre code de test est typique d'un cas + de test avec un objet fantaisie. +

+class TelnetTest extends UnitTestCase {
+    ...
+    function testConnection() {
+        $socket = &new MockSocket($this);
+        ...
+        $telnet = &new Telnet();
+        $telnet->connect($socket, 'Me', 'Secret');
+        ...
+    }
+}
+

+ C'est assez évident que vous ne pouvez descendre que d'un niveau. + Vous ne voudriez pas que votre application de haut niveau + crée tous les fichiers de bas niveau, sockets et autres connexions + à la base de données dont elle aurait besoin. + Elle ne connaîtrait pas les paramètres du constructeur de toute façon. +

+ La solution suivante est de passer l'objet créé sous la forme + d'un paramètre optionnel... +

+<?php
+require_once('socket.php');
+
+class Telnet {
+    ...
+    function &connect($ip, $port, $username, $password, $socket = false) {
+        if (!$socket) {
+            $socket = &new Socket($ip, $port);
+        }
+        $socket->read( ... );
+        ...
+        return $socket;
+    }
+}
+?>
+

+ Pour une solution rapide, c'est généralement suffisant. + Ensuite le test est très similaire : comme si le paramètre + était transmis formellement... +

+class TelnetTest extends UnitTestCase {
+    ...
+    function testConnection() {
+        $socket = &new MockSocket($this);
+        ...
+        $telnet = &new Telnet();
+        $telnet->connect('127.0.0.1', 21, 'Me', 'Secret', &$socket);
+        ...
+    }
+}
+

+ Le problème de cette approche tient dans son manque de netteté. + Il y a du code de test dans la classe principale et aussi + des paramètres transmis dans le scénario de test + qui ne sont jamais utilisés. Il s'agit là d'une approche + rapide et sale, mais qui ne reste pas moins efficace + dans la plupart des situations. +

+ Une autre solution encore est de laisser un objet fabrique + s'occuper de la création... +

+<?php
+require_once('socket.php');
+
+class Telnet {
+    function Telnet(&$network) {
+        $this->_network = &$network;
+    }
+    ...
+    function &connect($ip, $port, $username, $password) {
+        $socket = &$this->_network->createSocket($ip, $port);
+        $socket->read( ... );
+        ...
+        return $socket;
+    }
+}
+?>
+

+ Il s'agit là probablement de la réponse la plus travaillée + étant donné que la création est maintenant située + dans une petite classe spécialisée. La fabrique réseau + peut être testée séparément et utilisée en tant que fantaisie + quand nous testons la classe telnet... +

+class TelnetTest extends UnitTestCase {
+    ...
+    function testConnection() {
+        $socket = &new MockSocket($this);
+        ...
+        $network = &new MockNetwork($this);
+        $network->setReturnReference('createSocket', $socket);
+        $telnet = &new Telnet($network);
+        $telnet->connect('127.0.0.1', 21, 'Me', 'Secret');
+        ...
+    }
+}
+

+ Le problème reste que nous ajoutons beaucoup de classes + à la bibliothèque. Et aussi que nous utilisons beaucoup + de fabriques ce qui rend notre code un peu moins intuitif. + La solution la plus flexible, mais aussi la plus complexe. +

+ Peut-on trouver un juste milieu ? +

+ +

Méthode fabrique protégée

+ Il existe une technique pour palier à ce problème + sans créer de nouvelle classe dans l'application; + par contre elle induit la création d'une sous-classe au moment du test. + Premièrement nous déplaçons la création de la socket dans sa propre méthode... +

+<?php
+require_once('socket.php');
+
+class Telnet {
+    ...
+    function &connect($ip, $port, $username, $password) {
+        $socket = &$this->_createSocket($ip, $port);
+        $socket->read( ... );
+        ...
+    }
+    
+    function &_createSocket($ip, $port) {
+        return new Socket($ip, $port);
+    }
+}
+?>
+

+ Il s'agit là de la seule modification dans le code de l'application. +

+ Pour le scénario de test, nous devons créer + une sous-classe de manière à intercepter la création de la socket... +

+class TelnetTestVersion extends Telnet {
+    var $_mock;
+    
+    function TelnetTestVersion(&$mock) {
+        $this->_mock = &$mock;
+        $this->Telnet();
+    }
+    
+    function &_createSocket() {
+        return $this->_mock;
+    }
+}
+

+ Ici j'ai déplacé la fantaisie dans le constructeur, + mais un setter aurait fonctionné tout aussi bien. + Notez bien que la fantaisie est placée dans une variable + d'objet avant que le constructeur ne soit attaché. + C'est nécessaire dans le cas où le constructeur appelle + connect(). + Autrement il pourrait donner un valeur nulle à partir de + _createSocket(). +

+ Après la réalisation de tout ce travail supplémentaire + le scénario de test est assez simple. + Nous avons juste besoin de tester notre nouvelle classe à la place... +

+class TelnetTest extends UnitTestCase {
+    ...
+    function testConnection() {
+        $socket = &new MockSocket($this);
+        ...
+        $telnet = &new TelnetTestVersion($socket);
+        $telnet->connect('127.0.0.1', 21, 'Me', 'Secret');
+        ...
+    }
+}
+

+ Cette nouvelle classe est très simple bien sûr. + Elle ne fait qu'initier une valeur renvoyée, à la manière + d'une fantaisie. Ce serait pas mal non plus si elle pouvait + vérifier les paramètres entrants. + Exactement comme un objet fantaisie. + Il se pourrait bien que nous ayons à réaliser cette astuce régulièrement : + serait-il possible d'automatiser la création de cette sous-classe ? +

+ +

Un objet fantaisie partiel

+ Bien sûr la réponse est "oui" + ou alors j'aurais arrêté d'écrire depuis quelques temps déjà ! + Le test précédent a représenté beaucoup de travail, + mais nous pouvons générer la sous-classe en utilisant + une approche à celle des objets fantaisie. +

+ Voici donc une version avec objet fantaisie partiel du test... +

+Mock::generatePartial(
+        'Telnet',
+        'TelnetTestVersion',
+        array('_createSocket'));
+
+class TelnetTest extends UnitTestCase {
+    ...
+    function testConnection() {
+        $socket = &new MockSocket($this);
+        ...
+        $telnet = &new TelnetTestVersion($this);
+        $telnet->setReturnReference('_createSocket', $socket);
+        $telnet->Telnet();
+        $telnet->connect('127.0.0.1', 21, 'Me', 'Secret');
+        ...
+    }
+}
+

+ La fantaisie partielle est une sous-classe de l'original + dont on aurait "remplacé" les méthodes sélectionnées + avec des versions de test. L'appel à generatePartial() + nécessite trois paramètres : la classe à sous classer, + le nom de la nouvelle classe et une liste des méthodes à simuler. +

+ Instancier les objets qui en résultent est plutôt délicat. + L'unique paramètre du constructeur d'un objet fantaisie partiel + est la référence du testeur unitaire. + Comme avec les objets fantaisie classiques c'est nécessaire + pour l'envoi des résultats de test en réponse à la vérification des attentes. +

+ Une nouvelle fois le constructeur original n'est pas lancé. + Indispensable dans le cas où le constructeur aurait besoin + des méthodes fantaisie : elles n'ont pas encore été initiées ! + Nous initions les valeurs retournées à cet instant et + ensuite lançons le constructeur avec ses paramètres normaux. + Cette construction en trois étapes de "new", + suivie par la mise en place des méthodes et ensuite + par la lancement du constructeur proprement dit est + ce qui distingue le code d'un objet fantaisie partiel. +

+ A part pour leur construction, toutes ces méthodes + fantaisie ont les mêmes fonctionnalités que dans + le cas des objets fantaisie et toutes les méthodes + non fantaisie se comportent comme avant. + Nous pouvons mettre en place des attentes très facilement... +

+class TelnetTest extends UnitTestCase {
+    ...
+    function testConnection() {
+        $socket = &new MockSocket($this);
+        ...
+        $telnet = &new TelnetTestVersion($this);
+        $telnet->setReturnReference('_createSocket', $socket);
+        $telnet->expectOnce('_createSocket', array('127.0.0.1', 21));
+        $telnet->Telnet();
+        $telnet->connect('127.0.0.1', 21, 'Me', 'Secret');
+        ...
+        $telnet->tally();
+    }
+}
+

+ +

Tester moins qu'une classe

+ Les méthodes issues d'un objet fantaisie n'ont pas + besoin d'être des méthodes fabrique, Il peut s'agir + de n'importe quelle sorte de méthode. + Ainsi les objets fantaisie partiels nous permettent + de prendre le contrôle de n'importe quelle partie d'une classe, + le constructeur excepté. Nous pourrions même aller jusqu'à + créer des fantaisies sur toutes les méthodes à part celle + que nous voulons effectivement tester. +

+ Cette situation est assez hypothétique, étant donné + que je ne l'ai jamais essayée. Je suis ouvert à cette possibilité, + mais je crains qu'en forçant la granularité d'un objet + on n'obtienne pas forcément un code de meilleur qualité. + Personnellement j'utilise les objets fantaisie partiels + comme moyen de passer outre la création ou alors + de temps en temps pour tester le modèle de conception TemplateMethod. +

+ Pour choisir le mécanisme à utiliser, on en revient + toujours aux standards de code de votre projet. +

+ +

Documentation sur les objets fantaisie partiels

Le problème de l'injection dans un objet fantaisie

Méthode fabrique protégée

Un objet fantaisie partiel

Tester moins qu'une classe