<?xml version="1.0" encoding="ISO-8859-1" ?>
<page title="Documentation sur les objets fantaisie" here="Les objets fantaisie">
    <long_title>Documentation SimpleTest : les objets fantaise</long_title>
    <content>
        <section name="quoi" title="Que sont les objets fantaisie ?">
            <p>
                Les objets fantaisie - ou &quot;mock objects&quot; en anglais - ont deux rles pendant un scnario de test : acteur et critique.
            </p>
            <p>
                Le comportement d'acteur est celui de simuler des objets difficiles  initialiser ou trop consommateurs en temps pendant un test. Le cas classique est celui de la connexion  une base de donnes. Mettre sur pied une base de donnes de test au lancement de chaque test ralentirait considrablement les tests et en plus exigerait l'installation d'un moteur de base de donnes ainsi que des donnes sur la machine de test. Si nous pouvons simuler la connexion et renvoyer des donnes  notre guise alors non seulement nous gagnons en pragmatisme sur les tests mais en sus nous pouvons nourrir notre base avec des donnes falsifies et voir comment il rpond. Nous pouvons simuler une base de donnes en suspens ou d'autres cas extrmes sans avoir  crer une vritable panne de base de donnes. En d'autres termes nous pouvons gagner en contrle sur l'environnement de test.
            </p>
            <p>
                Si les objets fantaisie ne se comportaient que comme des acteurs alors on les connatrait sous le nom de <a local="server_stubs_documentation">bouchons serveur</a>.
            </p>
            <p>
                Cependant non seulement les objets fantaisie jouent un rle (en fournissant  la demande les valeurs requises) mais en plus ils sont aussi sensibles aux messages qui leur sont envoys (par le biais d'attentes). En posant les paramtres attendus d'une mthode ils agissent comme des gardiens : un appel sur eux doit tre ralis correctement. Si les attentes ne sont pas atteintes ils nous pargnent l'effort de l'criture d'une assertion de test avec chec en ralisant cette tche  notre place. Dans le cas d'une connexion  une base de donnes imaginaire ils peuvent tester si la requte, disons SQL, a bien t form par l'objet qui utilise cette connexion. Mettez-les sur pied avec des attentes assez prcises et vous verrez que vous n'aurez presque plus d'assertion  crire manuellement.
            </p>
        </section>
        <section name="creation" title="Crer des objets fantaisie">
            <p>
                Comme pour la cration des bouchons serveur, tout ce dont nous avons besoin c'est d'un classe existante. La fameuse connexion  une base de donnes qui ressemblerait ...
<php><![CDATA[
<strong>class DatabaseConnection {
    function DatabaseConnection() {
    }
    
    function query() {
    }
    
    function selectQuery() {
    }
}</strong>
]]></php>
                Cette classe n'a pas encore besoin d'tre implmente. Pour en crer sa version fantaisie nous devons juste inclure la librairie d'objet fantaisie puis lancer le gnrateur...
<php><![CDATA[
<strong>require_once('simpletest/unit_tester.php');
require_once('simpletest/mock_objects.php');
require_once('database_connection.php');

Mock::generate('DatabaseConnection');</strong>
]]></php>
                Ceci gnre une classe clone appele <code>MockDatabaseConnection</code>. Nous pouvons dsormais crer des instances de cette nouvelle classe  l'intrieur mme de notre scnario de test...
<php><![CDATA[
require_once('simpletest/unit_tester.php');
require_once('simpletest/mock_objects.php');
require_once('database_connection.php');

Mock::generate('DatabaseConnection');
<strong>
class MyTestCase extends UnitTestCase {
    
    function testSomething() {
        $connection = &new MockDatabaseConnection($this);
    }
}</strong>
]]></php>
                Contrairement aux bouchons, le constructeur d'une classe fantaisie a besoin d'une rfrence au scnario de test pour pouvoir transmettre les succs et les checs pendant qu'il vrifie les attentes. Concrtement a veut dire que les objets fantaisie ne peuvent tre utiliss qu'au sein d'un scnario de test. Malgr tout, cette puissance supplmentaire implique que les bouchons ne sont que rarement utiliss si des objets fantaisie sont disponibles.
            </p>
            <p>
                <a class="target" name="bouchon"><h2>Objets fantaisie en action</h2></a>
            </p>
            <p>
                La version fantaisie d'une classe contient toutes les mthodes de l'originale. De la sorte une opration comme <code><![CDATA[$connection->query()]]></code> est encore possible. Tout comme avec les bouchons, nous pouvons remplacer la valeur nulle renvoye par dfaut...
<php><![CDATA[
<strong>$connection->setReturnValue('query', 37);</strong>
]]></php>
                Dsormais  chaque appel de <code><![CDATA[$connection->query()]]></code> nous recevons comme rsultat 37. Tout comme avec les bouchons nous pouvons utiliser des jokers et surcharger le paramtre joker. Nous pouvons aussi ajouter des mthodes supplmentaires  l'objet fantaisie lors de sa gnration et lui choisir un nom de classe qui lui soit propre...
<php><![CDATA[
<strong>Mock::generate('DatabaseConnection', 'MyMockDatabaseConnection', array('setOptions'));</strong>
]]></php>
                Ici l'objet fantaisie se comportera comme si <code>setOptions()</code> existait dans la classe originale. C'est pratique si une classe a utilis le mcanisme <code>overload()</code> de PHP pour ajouter des mthodes dynamiques. Vous pouvez crer des fantaisies spciales pour simuler cette situation.
            </p>
            <p>
                Tous les modles disponibles avec les bouchons serveur le sont galement avec les objets fantaisie...
<php><![CDATA[
class Iterator {
    function Iterator() {
    }
    
    function next() {
    }
}
]]></php>
                Une nouvelle fois, supposons que cet itrateur ne retourne que du texte jusqu'au moment o il atteint son terme, quand il renvoie <code>false</code>. Nous pouvons le simuler avec...
<php><![CDATA[
Mock::generate('Iterator');

class IteratorTest extends UnitTestCase() {
    
    function testASequence() {<strong>
        $iterator = &new MockIterator($this);
        $iterator->setReturnValue('next', false);
        $iterator->setReturnValueAt(0, 'next', 'First string');
        $iterator->setReturnValueAt(1, 'next', 'Second string');</strong>
        ...
    }
}
]]></php>
                Au moment du premier appel  <code>next()</code> sur l'itrateur fantaisie il renverra tout d'abord &quot;First string&quot;, puis ce sera au tour de &quot;Second string&quot; au deuxime appel et ensuite pour tout appel suivant <code>false</code> sera renvoy. Ces valeurs renvoyes successivement sont prioritaires sur la valeur constante retourne. Cette dernire est un genre de valeur par dfaut si vous voulez.
            </p>
            <p>
                Reprenons aussi le conteneur d'information bouchonn avec des pairs clef / valeur...
<php><![CDATA[
class Configuration {
    function Configuration() {
    }
    
    function getValue($key) {
    }
}
]]></php>
                Il s'agit l d'une situation classique d'utilisation d'objets fantaisie tant donn que la configuration peut varier grandement de machine  machine : a contraint fortement la fiabilit de nos tests si nous l'utilisons directement. Le problme est que toutes les donnes nous parviennent  travers la mthode <code>getValue()</code> et que nous voulons des rsultats diffrents pour des clefs diffrentes. Heureusement les objets fantaisie ont un systme de filtrage...
<php><![CDATA[
<strong>$config = &new MockConfiguration($this);
$config->setReturnValue('getValue', 'primary', array('db_host'));
$config->setReturnValue('getValue', 'admin', array('db_user'));
$config->setReturnValue('getValue', 'secret', array('db_password'));</strong>
]]></php>
                Le paramtre en plus est une liste d'arguments  faire correspondre. Dans ce cas nous essayons de faire correspondre un unique argument : en l'occurrence la clef recherche. Maintenant que la mthode <code>getValue()</code> est invoque sur l'objet fantaisie...
<php><![CDATA[
$config->getValue('db_user')
]]></php>
                ...elle renverra &quot;admin&quot;. Elle le trouve en essayant de faire correspondre les arguments entrants dans sa liste d'arguments sortants les uns aprs les autres jusqu'au moment o une correspondance exacte est atteinte.
            </p>
            <p>
                Il y a des fois o vous souhaitez qu'un objet spcifique soit servi par la fantaisie plutt qu'une copie. De nouveau c'est identique au mcanisme des bouchons serveur...
<php><![CDATA[
class Thing {
}

class Vector {
    function Vector() {
    }
    
    function get($index) {
    }
}
]]></php>
                Dans ce cas vous pouvez placer une rfrence dans la liste renvoye par l'objet fantaisie...
<php><![CDATA[
$thing = new Thing();<strong>
$vector = &new MockVector($this);
$vector->setReturnReference('get', $thing, array(12));</strong>
]]></php>
                Avec cet arrangement vous savez qu' chaque appel de <code><![CDATA[$vector->get(12)]]></code> le mme <code>$thing</code> sera renvoy.
            </p>
        </section>
        <section name="attentes" title="Objets fantaisie en critique">
            <p>
                Mme si les bouchons serveur vous isolent du dsordre du monde rel, il ne s'agit l que de la moiti du bnfice potentiel. Vous pouvez avoir une classe de test recevant les messages ad hoc, mais est-ce que votre nouvelle classe renvoie bien les bons ? Le tester peut devenir cafouillis sans une librairie d'objets fantaisie.
            </p>
            <p>
                Pour l'exemple, prenons une classe <code>SessionPool</code>  laquelle nous allons ajouter une fonction de log. Plutt que de complexifier la classe originale, nous souhaitons ajouter ce comportement avec un dcorateur (GOF). Pour l'instant le code de <code>SessionPool</code> ressemble ...
<php><![CDATA[
<strong>class SessionPool {
    function SessionPool() {
        ...
    }
    
    function &findSession($cookie) {
        ...
    }
    ...
}

class Session {
    ...
}</strong>
]]>
</php>
                Alors que pour notre code de log, nous avons...
<php><![CDATA[<strong>
class Log {
    function Log() {
        ...
    }
    
    function message() {
        ...
    }
}

class LoggingSessionPool {
    function LoggingSessionPool(&$session_pool, &$log) {
        ...
    }
    
    function &findSession(\$cookie) {
        ...
    }
    ...
}</strong>
]]></php>
                Dans tout ceci, la seule classe  tester est <code>LoggingSessionPool</code>. En particulier, nous voulons vrifier que la mthode <code>findSession()</code> est appele avec le bon identifiant de session au sein du cookie et qu'elle renvoie bien le message &quot;Starting session $cookie&quot; au loggueur.
            </p>
            <p>
                Bien que nous ne testions que quelques lignes de code de production, voici la liste des choses  faire dans un scnario de test conventionnel :
                <ol>
                    <li>Crer un objet de log.</li>
                    <li>Indiquer le rpertoire d'criture du fichier de log.</li>
                    <li>Modifier les droits sur le rpertoire pour pouvoir y crire le fichier.</li>
                    <li>Crer un objet <code>SessionPool</code>.</li>
                    <li>Lancer une session, ce qui demande probablement pas mal de choses.</li>
                    <li>Invoquer <code>findSession()</code>.</li>
                    <li>Lire le nouvel identifiant de session (en esprant qu'il existe un accesseur !).</li>
                    <li>Lever une assertion de test pour vrifier que cet identifiant correspond bien au cookie.</li>
                    <li>Lire la dernire ligne du fichier de log.</li>
                    <li>Supprimer avec une (ou plusieurs) expression rationnelle les timestamps de log en trop, etc.</li>
                    <li>Vrifier que le message de session est bien dans le texte.</li>
                </ol>
                Pas tonnant que les dveloppeurs dtestent crire des tests quand ils sont aussi ingrats. Pour rendre les choses encore pire,  chaque fois que le format de log change ou bien que la mthode de cration des sessions change, nous devons rcrire une partie des tests alors mme qu'ils ne testent pas ces parties du systme. Nous sommes en train de prparer le cauchemar pour les dveloppeurs de ces autres classes.
            </p>
            <p>
                A la place, voici la mthode complte pour le test avec un peu de magie via les objets fantaisie...
<php><![CDATA[
Mock::generate('Session');
Mock::generate('SessionPool');
Mock::generate('Log');

class LoggingSessionPoolTest extends UnitTestCase {
    ...
    function testFindSessionLogging() {<strong>
        $session = &new MockSession($this);
        $pool = &new MockSessionPool($this);
        $pool->setReturnReference('findSession', $session);
        $pool->expectOnce('findSession', array('abc'));
        
        $log = &new MockLog($this);
        $log->expectOnce('message', array('Starting session abc'));
        
        $logging_pool = &new LoggingSessionPool($pool, $log);
        $this->assertReference($logging_pool->findSession('abc'), $session);
        $pool->tally();
        $log->tally();</strong>
    }
}
]]></php>
                Commenons par crire une session simulacre. Pas la peine d'tre trop pointilleux avec celle-ci puisque la vrification de la session dsire est effectue ailleurs. Nous avons juste besoin de vrifier qu'il s'agit de la mme que celle qui vient du groupe commun des sessions.
            </p>
            <p>
                <code>findSession()</code> est un mthode fabrique dont la simulation est dcrite <a href="#stub">plus haut</a>. Le point de dpart vient avec le premier appel <code>expectOnce()</code>. Cette ligne indique qu' chaque fois que <code>findSession()</code> est invoqu sur l'objet fantaisie, il vrifiera les arguments entrant. S'il ne reoit que la chane &quot;abc&quot; en tant qu'argument alors un succs est envoy au testeur unitaire, sinon c'est un chec qui est gnr. Il s'agit l de la partie qui teste si nous avons bien la bonne session. La liste des arguments suit une format identique  celui qui prcise les valeurs renvoyes. Vous pouvez avoir des jokers et des squences et l'ordre de l'valuation restera le mme.
            </p>
            <p>
                Si l'appel n'est jamais effectu alors n'est gnr ni le succs, ni l'chec. Pour contourner cette limitation, nous devons dire  l'objet fantaisie que le test est termin : il pourra alors dcider si les attentes ont t rpondues. L'assertion du testeur unitaire de ceci est dclenche par l'appel <code>tally()</code>  la fin du test.
            </p>
            <p>
                Nous utilisons le mme modle pour mettre sur pied le loggueur fantaisie. Nous lui indiquons que <code>message()</code> devrait tre invoqu une fois et une fois seulement avec l'argument &quot;Starting session abc&quot;. En testant les arguments d'appel, plutt que ceux de sortie du loggueur, nous isolons le test de tout modification dans le loggueur.
            </p>
            <p>
                Nous commenons le lancement nos tests  la cration du nouveau <code>LoggingSessionPool</code> et nous l'alimentons avec nos objets fantaisie juste crs. Dsormais tout est sous contrle. Au final nous confirmons que le <code>$session</code> donn au dcorateur est bien celui reu et prions les objets fantaisie de lancer leurs tests de comptage d'appel interne avec les appels <code>tally()</code>.
            </p>
            <p>
                Il y a encore pas mal de code de test, mais ce code est trs strict. S'il vous semble encore terrifiant il l'est bien moins que si nous avions essay sans les objets fantaisie et ce test en particulier, interactions plutt que rsultat, est toujours plus difficile  mettre en place. Le plus souvent vous aurez besoin de tester des situations plus complexes sans ce niveau ni cette prcision. En outre une partie peut tre remanie avec la mthode de scnario de test <code>setUp()</code>.
            </p>
            <p>
                Voici la liste complte des attentes que vous pouvez placer sur un objet fantaisie avec <a href="http://www.lastcraft.com/simple_test.php">SimpleTest</a>...
                <table><thead>
                    <tr><th>Attente</th><th>Ncessite <code>tally()</code></th></tr>
                    </thead><tbody><tr>
                        <td><code>expectArguments($method, $args)</code></td>
                        <td style="text-align: center">Non</td>
                    </tr>
                    <tr>
                        <td><code>expectArgumentsAt($timing, $method, $args)</code></td>
                        <td style="text-align: center">Non</td>
                    </tr>
                    <tr>
                        <td><code>expectCallCount($method, $count)</code></td>
                        <td style="text-align: center">Oui</td>
                    </tr>
                    <tr>
                        <td><code>expectMaximumCallCount($method, $count)</code></td>
                        <td style="text-align: center">Non</td>
                    </tr>
                    <tr>
                        <td><code>expectMinimumCallCount($method, $count)</code></td>
                        <td style="text-align: center">Oui</td>
                    </tr>
                    <tr>
                        <td><code>expectNever($method)</code></td>
                        <td style="text-align: center">Non</td>
                    </tr>
                    <tr>
                        <td><code>expectOnce($method, $args)</code></td>
                        <td style="text-align: center">Oui</td>
                    </tr>
                    <tr>
                        <td><code>expectAtLeastOnce($method, $args)</code></td>
                        <td style="text-align: center">Oui</td>
                    </tr>
                </tbody></table>
                O les paramtres sont...
                <dl>
                    <dt class="new_code">$method</dt>
                    <dd>Le nom de la mthode, sous la forme d'une chane,  laquelle la condition doit tre applique.</dd>
                    <dt class="new_code">$args</dt>
                    <dd>
                        Les arguments sous la forme d'une liste. Les jokers peuvent tre inclus de la mme manire qu'avec <code>setReturn()</code>. Cet argument est optionnel pour <code>expectOnce()</code> et <code>expectAtLeastOnce()</code>.
                    </dd>
                    <dt class="new_code">$timing</dt>
                    <dd>
                        Le seul point dans le temps pour tester la condition. Le premier appel commence  zro.
                    </dd>
                    <dt class="new_code">$count</dt>
                    <dd>Le nombre d'appels attendu.</dd>
                </dl>
                La mthode <code>expectMaximumCallCount()</code> est lgrement diffrente dans le sens o elle ne pourra gnrer qu'un chec. Elle reste silencieuse si la limite n'est jamais atteinte.
            </p>
            <p>
                Comme avec les assertions dans les scnarios de test, toutes ces attentes peuvent accepter une surcharge de message sous la forme d'un paramtre supplmentaire. Par ailleurs le message d'chec original peut tre inclus dans le rsultat avec &quot;%s&quot;.
            </p>
        </section>
        <section name="approches" title="D'autres approches">
            <p>
                Il existe trois approches pour crer des objets fantaisie en comprenant celle utilise par SimpleTest. Les coder  la main en utilisant une classe de base, les gnrer dans un fichier ou les gnrer dynamiquement  la vole.
            </p>
            <p>
                Les objets fantaisie gnrs avec <a local="simple_test">SimpleTest</a> sont dynamiques. Ils sont crs  l'excution dans la mmoire, grce  <code>eval()</code>, plutt qu'crits dans un fichier. Cette opration les rend facile  crer, en une seule ligne, surtout par rapport  leur cration  la main dans une hirarchie de classe parallle. Le problme avec ce comportement tient gnralement dans la mise en place des tests proprement dits. Si les objets originaux changent les versions fantaisie sur lesquels reposent les tests, une dsynchronisation peut subvenir. Cela peut aussi arriver avec l'approche en hirarchie parallle, mais c'est dtect beaucoup plus vite.
            </p>
            <p>
                Bien sr, la solution est d'ajouter de vritables tests d'intgration. Vous n'en avez pas besoin de beaucoup et le ct pratique des objets fantaisie fait plus que compenser la petite dose de test supplmentaire. Vous ne pouvez pas avoir confiance dans du code qui ne serait test que par des objets fantaisie.
            </p>
            <p>
                Si vous restez dtermin de construire des librairies statiques d'objets fantaisie parce que vous souhaitez muler un comportement trs spcifique, vous pouvez y parvenir grce au gnrateur de classe de SimpleTest. Dans votre fichier librairie, par exemple <em>mocks/connection.php</em> pour une connexion  une base de donnes, crer un objet fantaisie et provoquer l'hritage pour hriter pour surcharger des mthodes spciales ou ajouter des prrglages...
<php><![CDATA[
<?php
    require_once('simpletest/mock_objects.php');
    require_once('../classes/connection.php');
<strong>
    Mock::generate('Connection', 'BasicMockConnection');
    class MockConnection extends BasicMockConnection {
        function MockConnection(&$test, $wildcard = '*') {
            $this->BasicMockConnection($test, $wildcard);
            $this->setReturn('query', false);
        }
    }</strong>
?>
]]></php>
                L'appel <code>generate</code> dit au gnrateur de classe d'en crer une appele <code>BasicMockConnection</code> plutt que la plus courante <code>MockConnection</code>. Ensuite nous hritons  partir de celle-ci pour obtenir notre version de <code>MockConnection</code>. En interceptant de cette manire nous pouvons ajouter un comportement, ici transformer la valeur par dfaut de <code>query()</code> en &quot;false&quot;.
                En utilisant le nom par dfaut nous garantissons que le gnrateur de classe fantaisie n'en recrera pas une autre diffrente si il est invoqu ailleurs dans les tests. Il ne crera jamais de classe si elle existe dj. Aussi longtemps que le fichier ci-dessus est inclus avant alors tous les tests qui gnraient <code>MockConnection</code> devraient utiliser notre version  prsent. Par contre si nous avons une erreur dans l'ordre et que la librairie de fantaisie en cre une d'abord alors la cration de la classe chouera tout simplement.
            </p>
            <p>
                Utiliser cette astuce si vous vous trouvez avec beaucoup de comportement en commun sur les objets fantaisie ou si vous avez de frquents problmes d'intgration plus tard dans les tapes de test.
            </p>
        </section>
        <section name="autres_testeurs" title="Je pense que SimpleTest pue !">
            <p>
                Mais au moment d'crire ces lignes c'est le seul  grer les objets fantaisie, donc vous tes bloqu avec lui ?
            </p>
            <p>
                Non, pas du tout.
                <a local="simple_test">SimpleTest</a> est une bote  outils et parmi ceux-ci on trouve les objets fantaisie qui peuvent tre utiliss indpendamment. Supposons que vous avez votre propre testeur unitaire favori et que tous vos tests actuels l'utilisent. Prtendez que vous avez appel votre tester unitaire PHPUnit (c'est ce que tout le monde a fait) et que la classe principale de test ressemble ...
<php><![CDATA[
class PHPUnit {
    function PHPUnit() {
    }
    
    function assertion($message, $assertion) {
    }
    ...
}
]]></php>
                La seule chose que la mthode <code>assertion()</code> ralise, c'est de prparer une sortie embellie alors le paramtre boolien de l'assertion sert  dterminer s'il s'agit d'une erreur ou d'un succs. Supposons qu'elle est utilise de la manire suivante...
<php><![CDATA[
$unit_test = new PHPUnit();
$unit_test>assertion('I hope this file exists', file_exists('my_file'));
]]></php>
                Comment utiliser les objets fantaisie avec ceci ?
            </p>
            <p>
                Il y a une mthode protge sur la classe de base des objets fantaisie : elle s'appelle <code>_assertTrue()</code>. En surchargeant cette mthode nous pouvons utiliser notre propre format d'assertion. Nous commenons avec une sous-classe, dans <em>my_mock.php</em>...
<php><![CDATA[
<strong><?php
    require_once('simpletest/mock_objects.php');
    
    class MyMock extends SimpleMock() {
        function MyMock(&$test, $wildcard) {
            $this->SimpleMock($test, $wildcard);
        }
        
        function _assertTrue($assertion, $message) {
            $test = &$this->getTest();
            $test->assertion($message, $assertion);
        }
    }
?></strong>
]]></php>
                Maintenant une instance de <code>MyMock</code> crera un objet qui parle le mme langage que votre testeur. Bien sr le truc c'est que nous crons jamais un tel objet : le gnrateur s'en chargera. Nous avons juste besoin d'une ligne de code supplmentaire pour dire au gnrateur d'utiliser vos nouveaux objets fantaisie...
<php><![CDATA[
<?php
    require_once('simpletst/mock_objects.php');
    
    class MyMock extends SimpleMock() {
        function MyMock($test, $wildcard) {
            $this->SimpleMock(&$test, $wildcard);
        }
        
        function _assertTrue($assertion, $message , &$test) {
            $test->assertion($message, $assertion);
        }
    }<strong>
    SimpleTestOptions::setMockBaseClass('MyMock');</strong>
?>
]]></php>
                A partir de maintenant vous avez juste  inclure <em>my_mock.php</em>  la place de la version par dfaut <em>simple_mock.php</em> et vous pouvez introduire des objets fantaisie dans votre suite de tests existants.
            </p>
        </section>
    </content>
    <internal>
        <link>
            <a href="#quoi">Que sont les objets fantaisie ?</a>
        </link>
        <link>
            <a href="#creation">Crer des objets fantaisie</a>.
        </link>
        <link>
            <a href="#bouchon">L'objet fantaisie - acteur</a> ou bouchon.
        </link>
        <link>
            <a href="#attentes">L'objet fantaisie - critique</a> avec des attentes.
        </link>
        <link>
            <a href="#approches">D'autres approches</a> y compris des librairies d'objets fantaisie.
        </link>
        <link>
            Utiliser les objets fantaisie avec <a href="#autres_testeurs">d'autres testeurs unitaires</a>.
        </link>
    </internal>
    <external>
        <link>
            L'article originel sur <a href="http://www.mockobjects.com/">les objets fantaisie</a>.
        </link>
        <link>
            La page du projet SimpleTest sur <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>.
        </link>
        <link>
            La page d'accueil de SimpleTest sur <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>.
        </link>
    </external>
    <meta>
        <keywords>
            dveloppement logiciel,
            programmation en php,
            outils de dveloppement logiciel,
            tutoriel php,
            scripts php gratuits,
            architecture,
            ressources php,
            mock objects,
            objets fantaisie,
            junit,
            test php,
            test unitaire,
            tester en php
        </keywords>
    </meta>
</page>