Documentation sur les objets fantaisie

Que sont les objets fantaisie ?

Les objets fantaisie - ou "mock objects" en anglais - ont deux rôles pendant un scénario de test : acteur et critique.

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 données. Mettre sur pied une base de données de test au lancement de chaque test ralentirait considérablement les tests et en plus exigerait l'installation d'un moteur de base de données ainsi que des données sur la machine de test. Si nous pouvons simuler la connexion et renvoyer des données à notre guise alors non seulement nous gagnons en pragmatisme sur les tests mais en sus nous pouvons nourrir notre base avec des données falsifiées et voir comment il répond. Nous pouvons simuler une base de données en suspens ou d'autres cas extrêmes sans avoir à créer une véritable panne de base de données. En d'autres termes nous pouvons gagner en contrôle sur l'environnement de test.

Si les objets fantaisie ne se comportaient que comme des acteurs alors on les connaîtrait sous le nom de bouchons serveur. Il s'agissait originairement d'un patron de conception identifié par Robert Binder (Testing object-oriented systems: models, patterns, and tools, Addison-Wesley) en 1999.

Un bouchon serveur est une simulation d'un objet ou d'un composant. Il doit remplacer exactement un composant dans un système en vue d'effectuer des tests ou un prototypage, tout en restant ultra-léger. Il permet aux tests de s'exécuter plus rapidement, ou si la classe simulée n'a pas encore été écrite, de se lancer tout court.

Cependant non seulement les objets fantaisie jouent un rôle (en fournissant à la demande les valeurs requises) mais en plus ils sont aussi sensibles aux messages qui leur sont envoyés (par le biais d'attentes). En posant les paramètres attendus d'une méthode ils agissent comme des gardiens : un appel sur eux doit être réalisé correctement. Si les attentes ne sont pas atteintes ils nous épargnent l'effort de l'écriture d'une assertion de test avec échec en réalisant cette tâche à notre place.

Dans le cas d'une connexion à une base de données imaginaire ils peuvent tester si la requête, disons SQL, a bien été formé par l'objet qui utilise cette connexion. Mettez-les sur pied avec des attentes assez précises et vous verrez que vous n'aurez presque plus d'assertion à écrire manuellement.

Créer des objets fantaisie

Tout ce dont nous avons besoin est une classe existante ou une interface, par exemple une connexion à la base de données qui ressemblerait à...

class DatabaseConnection {
    function DatabaseConnection() { }
    function query($sql) { }
    function selectQuery($sql) { }
}

Pour en créer sa version fantaisie nous devons juste lancer le générateur...

require_once('simpletest/autorun.php');
require_once('database_connection.php');

Mock::generate('DatabaseConnection');

Ce code génère une classe clone appelée MockDatabaseConnection. Cette nouvelle classe lui ressemble en tout point, sauf qu'elle ne fait rien du tout.

Cette nouvelle classe est génératlement une sous-classe de DatabaseConnection. Malheureusement, il n'y as aucun moyen de créer une version fantaisie d'une classe avec une méthode final sans avoir une version fonctionnelle de cette méthode. Ce n'est pas pas très satisfaisant. Si la cible est une interface ou si les méthodes final existent dans la classe cible, alors une toute nouvelle classe est créée, elle implémente juste les même interfaces. Si vous essayer de faire passer cette classe à travers un indice de type qui spécifie le véritable nom de l'ancienne classe, alors il échouera. Du code qui forcerait un indice de type tout en utilisant des méthodes final ne pourrait probablement pas être testé efficacement avec des objets fantaisie.

Si vous voulez voir le code généré, il suffit de faire un print de la sortie de Mock::generate(). VOici le code généré pour la classe DatabaseConnection à la place de son interface...

class MockDatabaseConnection extends DatabaseConnection {
    public $mock;
    protected $mocked_methods = array('databaseconnection', 'query', 'selectquery');

    function MockDatabaseConnection() {
        $this->mock = new SimpleMock();
        $this->mock->disableExpectationNameChecks();
    }
    ...
    function DatabaseConnection() {
        $args = func_get_args();
        $result = &$this->mock->invoke("DatabaseConnection", $args);
        return $result;
    }
    function query($sql) {
        $args = func_get_args();
        $result = &$this->mock->invoke("query", $args);
        return $result;
    }
    function selectQuery($sql) {
        $args = func_get_args();
        $result = &$this->mock->invoke("selectQuery", $args);
        return $result;
    }
}

Votre sortie dépendra quelque peu de votre version précise de SimpleTest.

En plus des méthodes d'origine de la classe, vous en verrez d'autres pour faciliter les tests. Nous y reviendrons.

Nous pouvons désormais créer des instances de cette nouvelle classe à l'intérieur même de notre scénario de test...

require_once('simpletest/autorun.php');
require_once('database_connection.php');

Mock::generate('DatabaseConnection');

class MyTestCase extends UnitTestCase {

    function testSomething() {
        $connection = new MockDatabaseConnection();
    }
}

La version fantaisie contient toutles méthodes de l'originale. En outre, tous les indices de type seront préservés. Dison que nos méthodes de requête attend un objet Query...

class DatabaseConnection {
    function DatabaseConnection() { }
    function query(Query $query) { }
    function selectQuery(Query $query) { }
}

Si nous lui passons le mauvais type d'objet ou même pire un non-objet...

class MyTestCase extends UnitTestCase {

    function testSomething() {
        $connection = new MockDatabaseConnection();
        $connection->query('insert into accounts () values ()');
    }
}

...alors le code renverra une violation de typage, exactement comme on aurait pû s'y attendre avec la classe d'origine.

Si la version fantaisie implémente bien toutes les méthodes de l'originale, elle renvoit aussi systématiquement null. Et comme toutes les méthodes qui renvoient toujours null ne sont pas très utiles, nous avons besoin de leur faire dire autre chose...

Objets fantaisie en action

Changer le null renvoyé par la méthode fantaisie en autre chose est assez facile...

$connection->returns('query', 37)

Désormais à chaque appel de $connection->query() nous obtenons un résultat de 37. Il n'y a rien de particulier à cette valeur de 37. Cette valeur de retour peut être aussi compliqué que nécessaire.

Ici les paramètres ne sont pas significatifs, nous aurons systématiquement la même valeur en retour une fois initialisés de la sorte. Cela pourrait ne pas ressembler à une copie convaincante de notre connexion à la base de données, mais pour la demi-douzaine de lignes de code de notre méthode de test c'est généralement largement assez.

Sauf que les choses ne sont pas toujours si simples. Les itérateurs sont un problème récurrent, si par exemple renvoyer systématiquement la même valeur entraine une boucle infinie dans l'objet testé. Pour ces cas-là, nous avons besoin d'une séquence de valeurs. Supposons que nous avons un itérateur simple qui ressemble à...

class Iterator {
    function Iterator() { }
    function next() { }
}

Il s'agit là de l'itérateur le plus basique que nous puissions imaginer. Supponsons que cet itérateur ne renvoit que du texte jusqu'à ce qu'il atteigne la fin et qu'il renvoie alors un false, nous pouvons le simuler avec...

Mock::generate('Iterator');

class IteratorTest extends UnitTestCase() {

    function testASequence() {
        $iterator = new MockIterator();
        $iterator->returns('next', false);
        $iterator->returnsAt(0, 'next', 'First string');
        $iterator->returnsAt(1, 'next', 'Second string');
        ...
    }
}

Quand next() est appelé par le MockIterator il commencera par renvoyer "First string", au deuxième passage "Second string" sera renvoyé et sur n'importe quel autre appel false sera renvoyé à son tour. Les valeurs renvoyées les unes après les autres auront la priorité sur la valeur constante. Cette dernière est la valeur par défaut en quelque sorte.

Une autre situation délicate serait une opération get() surchargée. Un exemple serait un conteneur d'information avec des pairs clef/valeur. Nous partons cette fois d'une classe de configuration telle...

class Configuration {
    function Configuration() { ... }
    function get($key) { ... }
}

C'est une situation courante pour utiliser des objets fantaisie, étant donné que la véritable configuration sera différente d'une machine à l'autre et parfois même d'un test à l'autre. Cependant un problème apparaît quand toutes les données passent par la méthode get() et que nous souhaitons quand même des résultats différents pour des clefs différentes. Par chance les objets fantaisie ont un système de filtre...

$config = &new MockConfiguration();
$config->returns('get', 'primary', array('db_host'));
$config->returns('get', 'admin', array('db_user'));
$config->returns('get', 'secret', array('db_password'));

Le dernier paramètre est une liste d'arguements pour vérifier une correspondance. Dans ce cas, nous essayons de faire correspondre un argument qui se trouve être la clef de recherche. Désormais quand l'objet fantaisie voit sa méthode get() invoquée...

$config->get('db_user')

...il renverra "admin". Il trouve cette valeur en essayant de faire correspondre l'argument reçu à ceux de ses propres listes : dès qu'une correspondance complète est trouvé, il s'arrête.

Vous pouvez préciser un argument par défaut via...

$config->returns('get', false, array('*'));

Ce n'est pas la même chose que de définir la valeur renvoyée sans aucun arguement...

$config->returns('get', false);

Dans le premier cas, il acceptera n'importe quel argument, mais il en faut au moins un. Dans le deuxième cas, n'importe quel nombre d'arguments fera l'affaire and il agit comme un attrape-tout après toutes les autres vérifications. Notez que si - dans le premier cas - nous ajoutons d'autres options avec paramètre unique après le joker, alors elle seront ignorés puisque le joker fera la première correspondance. Avec des listes complexes de paramètres, l'ordre devient important au risque de voir la correspondance souhaitée masqué par un joker apparu plus tôt. Déclarez les plus spécifiques d'abord si vous n'êtes pas sûr.

Il y a des moments où vous souhaitez qu'une référence bien spécifique soit servie par l'objet fantaisie plutôt qu'une copie. C'est plutôt rare pour dire le moins, mais vous pourriez être en train de simuler un conteneur qui détiendrait des primitives, tels des chaînes de caractères. Par exemple.

class Pad {
    function Pad() { }
    function &note($index) { }
}

Dans ce cas, vous pouvez définir une référence dans la liste des valeurs retournées par l'objet fantaisie...

function testTaskReads() {
    $note = 'Buy books';
    $pad = new MockPad();
    $vector->returnsByReference('note', $note, array(3));
    $task = new Task($pad);
    ...
}

Avec cet assemblage vous savez qu'à chaque fois que $pad->note(3) est appelé il renverra toujours la même $note, même si celle-ci est modifiée.

Ces trois facteurs, timing, paramètres et références, peuvent être combinés orthogonalement. Par exemple...

$buy_books = 'Buy books';
$write_code = 'Write code';
$pad = new MockPad();
$vector->returnsByReferenceAt(0, 'note', $buy_books, array('*', 3));
$vector->returnsByReferenceAt(1, 'note', $write_code, array('*', 3));

Cela renverra une référence à $buy_books et ensuite à $write_code, mais seuleent si deux paramètres sont utilisés, le deuxième devant être l'entier 3. Cela devrait couvrir la plupart des situations.

Un dernier cas délicat reste : celui d'un objet créant un autre objet, plus connu sous le patron de conception "fabrique" (ou "factory"). Supponsons qu'à la réussite d'une requête à notre base de données imaginaire, un jeu d'enregistrements est renvoyé sous la forme d'un itérateur, où chaque appel au next() sur notre itérateur donne une ligne avant de s'arrêtre avec un false. Cela semble à un cauchemar à simuler, alors qu'en fait un objet fantaisie peut être créé avec les mécansimes ci-dessus...

Mock::generate('DatabaseConnection');
Mock::generate('ResultIterator');

class DatabaseTest extends UnitTestCase {

    function testUserFinderReadsResultsFromDatabase() {
        $result = new MockResultIterator();
        $result->returns('next', false);
        $result->returnsAt(0, 'next', array(1, 'tom'));
        $result->returnsAt(1, 'next', array(3, 'dick'));
        $result->returnsAt(2, 'next', array(6, 'harry'));

        $connection = new MockDatabaseConnection();
        $connection->returns('selectQuery', $result);

        $finder = new UserFinder($connection);
        $this->assertIdentical(
                $finder->findNames(),
                array('tom', 'dick', 'harry'));
    }
}

Désormais ce n'est que si notre $connection est appelée par la méthode query() que sera retourné le $result, lui-même s'arrêtant au troisième appel à next(). Ce devrait être suffisant comme information pour que notre classe UserFinder, la classe effectivement testée ici, fasse son boulot. Un test très précis et toujours pas de base de données en vue.

Nous pourrsion affiner ce test encore plus en insistant pour que la bonne requête soit envoyée...

$connection->returns('selectQuery', $result, array('select name, id from people'));

Là, c'est une mauvaise idée.

Niveau objet, nous avons un UserFinder qui parle à une base de données à travers une interface géante - l'ensemble du SQL. Imaginez si nous avions écrit un grand nombre de tests qui dépendrait désormais de cette requête SQL précise. Ces requêtes pourraient changer en masse pour tout un tas de raisons non liés à ce test spécifique. Par exemple, la règle pour les quotes pourrait changer, un nom de table pourrait évoluer, une table de liaison pourrait être ajouté, etc. Cela entrainerait une ré-écriture de tous les tests à chaque fois qu'un remaniement est fait, alors même que le comportement lui n'a pas bougé. Les tests sont censés aider au remaniement, pas le bloquer. Pour ma part, je préfère avoir une suite de tests qui passent quand je fais évoluer le nom des tables.

Et si vous voulez une règle, c'est toujours mieux de ne pas créer un objet fantaisie sur une grosse interface.

Par contrast, voici le test complet...

class DatabaseTest extends UnitTestCase {
    function setUp() { ... }
    function tearDown() { ... }

    function testUserFinderReadsResultsFromDatabase() {
        $finder = new UserFinder(new DatabaseConnection());
        $finder->add('tom');
        $finder->add('dick');
        $finder->add('harry');
        $this->assertIdentical(
                $finder->findNames(),
                array('tom', 'dick', 'harry'));
    }
}

Ce test est immunisé contre le changement de schéma. Il échouera uniquement si vous changez la fonctionnalité, ce qui correspond bien à ce qu'un test doit faire.

Il faut juste faire attention à ces méthodes setUp() et tearDown() que nous avons survolé pour l'instant. Elles doivent vider les tables de la base de données et s'assurer que le schéma est bien défini. Cela peut se engendrer un peu de travail supplémentaire, mais d'ordinaire ce type de code existe déjà - à commencer pour le déploiement.

Il y a au moins un endroit où vous aurez besoin d'objets fantaisie : c'est la simulation des erreurs. Exemple, la base de données tombe pendant que UserFinder fait son travail. Le UserFinder se comporte-t-il bien ?

class DatabaseTest extends UnitTestCase {

    function testUserFinder() {
        $connection = new MockDatabaseConnection();
        $connection->throwOn('selectQuery', new TimedOut('Ouch!'));
        $alert = new MockAlerts();
        $alert->expectOnce('notify', 'Database is busy - please retry');
        $finder = new UserFinder($connection, $alert);
        $this->assertIdentical($finder->findNames(), array());
    }
}

Nous avons transmis au UserFinder un objet $alert. Il va transmettre un certain nombre de belles notifications à l'interface utilisatuer en cas d'erreur. Nous préfèrerions éviter de saupoudrer notre code avec des commandes print codées en dur si nous pouvons l'éviter. Emballer les moyens de sortie veut dire que nous pouvons utiliser ce code partout. Et cela rend notre code plus facile.

Pour faire passer ce test, le finder doit écrire un message sympathique et compréhensible à l'$alert, plutôt que de propager l'exception. Jusque là, tout va bien.

Comment faire en sorte que la DatabaseConnection fantaisie soulève une exception ? Nous la générons avec la méthode throwOn sur l'objet fantaisie.

Enfin, que se passe-t-il si la méthode voulue pour la simulation n'existe pas encore ? Si vous définissez une valeur de retour sur une méthode absente, alors SimpleTest vous répondra avec une erreur. Et si vous utilisez __call() pour simuler des méthodes dynamiques ?

Les objets avec des interfaces dynamiques, avec __call, peuvent être problématiques dans l'implémentation courante des objets fantaisie. Vous pouvez en créer un autour de la méthode __call() mais c'est très laid. Et pourquoi un test devrait connaître quelque chose avec un niveau si bas dans l'implémentation. Il n'a besoin que de simuler l'appel.

Il y a bien moyen de contournement : ajouter des méthodes complémentaires à l'objet fantaisie à la génération.

Mock::generate('DatabaseConnection', 'MockDatabaseConnection', array('setOptions'));

Dans une longue suite de tests cela pourrait entraîner des problèmes, puisque vous avez probablement déjà une version fantaisie de la classe appellée MockDatabaseConnection sans les méthodes complémentaires. Le générateur de code ne générera pas la version fantaisie de la classe s'il en existe déjà une version avec le même nom. Il vous deviendra impossible de déterminer où est passée votre méthode si une autre définition a été lancé au préalable.

Pour pallier à ce problème, SimpleTest vous permet de choisir n'importe autre nom pour la nouvelle classe au moment même où vous ajouter les méthodes complémentaires.

Mock::generate('DatabaseConnection', 'MockDatabaseConnectionWithOptions', array('setOptions'));

Ici l'objet fantaisie se comportera comme si setOptions() existait bel et bien dans la classe originale.

Les objets fantaisie ne peuvent être utilisés qu'à l'intérieur des scénarios de test, étant donné qu'à l'apparition d'une attente ils envoient des messages directement au scénario de test courant. Les créer en dehors d'un scénario de test entraînera une erreur de run time quand une attente est déclenchée et qu'il n'y a pas de scénario de test en cours pour recevoir le message. Nous pouvons désormais couvrir ces attentes.

Objets fantaisie en tant que critiques

Même si les bouchons serveur isolent vos tests des perturbations du monde réel, ils n'apportent que le moitié des bénéfices possibles. Vous pouvez obtenir une classe de test qui reçoive les bons messages, mais cette nouvelle classe envoie-t-elle les bons ? Le tester peut devenir très bordélique sans une librairie d'objets fantaise.

Voici un exemple, prenons une classe PageController toute simple qui traitera un formulaire de paiement par carte bleue...

class PaymentForm extends PageController {
    function __construct($alert, $payment_gateway) { ... }
    function makePayment($request) { ... }
}

Cette classe a besoin d'un PaymentGateway pour parler concrètement à la banque. Il utilise aussi un objet Alert pour gérer les erreurs. Cette dernière classe parle à la page ou au template. Elle est responsable de l'affichage du message d'erreur et de la mise en valeur de tout champ du formulaire qui serait incorrecte.

Elle pourrait ressembler à...

class Alert {
    function warn($warning, $id) {
        print '<div class="warning">' . $warning . '</div>';
        print '<style type="text/css">#' . $id . ' { background-color: red }</style>';
    }
}

Portons notre attention à la méthode makePayment(). Si nous n'inscrivons pas un numéro "CVV2" (celui à trois chiffre au dos de la carte bleue), nous souhaitons afficher une erreur plutôt que d'essayer de traiter le paiement. En mode test...

<?php
require_once('simpletest/autorun.php');
require_once('payment_form.php');
Mock::generate('Alert');
Mock::generate('PaymentGateway');

class PaymentFormFailuresShouldBeGraceful extends UnitTestCase {

    function testMissingCvv2CausesAlert() {
        $alert = new MockAlert();
        $alert->expectOnce(
                    'warn',
                    array('Missing three digit security code', 'cvv2'));
        $controller = new PaymentForm($alert, new MockPaymentGateway());
        $controller->makePayment($this->requestWithMissingCvv2());
    }

    function requestWithMissingCvv2() { ... }
}
?>

Première question : où sont passés les assertions ?

L'appel à expectOnce('warn', array(...)) annonce à l'objet fantaisie qu'il faut s'attendre à un appel à warn() avant la fin du test. Quand il débouche sur l'appel à warn(), il vérifie les arguments. Si ceux-ci ne correspondent pas, alors un échec est généré. Il échouera aussi si la méthode n'est jamais appelée.

Non seulement le test ci-dessus s'assure que warn a bien été appelé, mais en plus qu'il a bien reçu la chaîne de caractère "Missing three digit security code" et même le tag "cvv2". L'équivalent de assertIdentical() est appliqué aux deux champs quand les paramètres sont comparés.

Si le contenu du message vous importe peu, surtout dans le cas d'une interface utilisateur qui change régulièrement, nous pouvons passer ce paramètre avec l'opérateur "*"...

class PaymentFormFailuresShouldBeGraceful extends UnitTestCase {

    function testMissingCvv2CausesAlert() {
        $alert = new MockAlert();
        $alert->expectOnce('warn', array('*', 'cvv2'));
        $controller = new PaymentForm($alert, new MockPaymentGateway());
        $controller->makePayment($this->requestWithMissingCvv2());
    }

    function requestWithMissingCvv2() { ... }
}

Nous pouvons même rendre le test encore moins spécifique en supprimant complètement la liste des paramètres...

function testMissingCvv2CausesAlert() {
    $alert = new MockAlert();
    $alert->expectOnce('warn');
    $controller = new PaymentForm($alert, new MockPaymentGateway());
    $controller->makePayment($this->requestWithMissingCvv2());
}

Ceci vérifiera uniquement si la méthode a été appelé, ce qui est peut-être un peu drastique dans ce cas. Plus tard, nous verrons comment alléger les attentes plus précisement.

Des tests sans assertions peuvent être à la fois compacts et très expressifs. Parce que nous interceptons l'appel sur le chemin de l'objet, ici de classe Alert, nous évitons de tester l'état par la suite. Cela évite les assertions dans les tests, mais aussi l'obligation d'ajouter des accesseurs uniquement pour les tests dans le code original. Si vous en arrivez à ajouter des accesseurs de ce type, on parle alors de "state based testing" dans le jargon ("test piloté par l'état"), il est probablement plus que temps d'utiliser des objets fantaisie dans vos tests. On peut alors parler de "behaviour based testing" (ou "test piloté par le comportement") : c'est largement mieux !

Ajoutons un autre test. Assurons nous que nous essayons même pas un paiement sans CVV2...

class PaymentFormFailuresShouldBeGraceful extends UnitTestCase {

    function testMissingCvv2CausesAlert() { ... }

    function testNoPaymentAttemptedWithMissingCvv2() {
        $payment_gateway = new MockPaymentGateway();
        $payment_gateway->expectNever('pay');
        $controller = new PaymentForm(new MockAlert(), $payment_gateway);
        $controller->makePayment($this->requestWithMissingCvv2());
    }

    ...
}

Vérifier une négation peut être très difficile dans les tests, mais expectNever() rend l'opération très facile heureusement.

expectOnce() et expectNever() sont suffisants pour la plupart des tests, mais occasionnellement vous voulez tester plusieurs évènements. D'ordinaire pour des raisons d'usabilité, nous souhaitons que tous les champs manquants du formulaire soient mis en relief, et pas uniquement le premier. Cela veut dire que nous devrions voir de multiples appels à Alert::warn(), pas juste un...

function testAllRequiredFieldsHighlightedOnEmptyRequest() {
    $alert = new MockAlert();
    $alert->expectAt(0, 'warn', array('*', 'cc_number'));
    $alert->expectAt(1, 'warn', array('*', 'expiry'));
    $alert->expectAt(2, 'warn', array('*', 'cvv2'));
    $alert->expectAt(3, 'warn', array('*', 'card_holder'));
    $alert->expectAt(4, 'warn', array('*', 'address'));
    $alert->expectAt(5, 'warn', array('*', 'postcode'));
    $alert->expectAt(6, 'warn', array('*', 'country'));
    $alert->expectCallCount('warn', 7);
    $controller = new PaymentForm($alert, new MockPaymentGateway());
    $controller->makePayment($this->requestWithMissingCvv2());
}

Le compteur dans expectAt() précise le nombre de fois que la méthode a déjà été appelée. Ici nous vérifions que chaque champ sera bien mis en relief.

Notez que nous sommes forcé de tester l'ordre en même temps. SimpleTest n'a pas encore de moyen pour éviter cela, mais dans une version future ce sera corrigé.

Voici la liste complètes des attentes que vous pouvez préciser sur une objet fantaisie dans SimpleTest. Comme pour les assertions, ces méthodes prennent en option un message d'erreur.

Attente	Description
expect($method, $args)	Les arguements doivent correspondre si appelés
expectAt($timing, $method, $args)	Les arguements doiven correspondre si appelés lors du passage numéro $timing
expectCallCount($method, $count)	La méthode doit être appelée exactement $count fois
expectMaximumCallCount($method, $count)	La méthode ne doit pas être appelée plus de $count fois
expectMinimumCallCount($method, $count)	La méthode ne doit pas être appelée moins de $count fois
expectNever($method)	La méthode ne doit jamais être appelée
expectOnce($method, $args)	La méthode ne doit être appelée qu'une seule fois et avec les arguments (en option)
expectAtLeastOnce($method, $args)	La méthode doit être appelée au moins une seule fois et toujours avec au moins un des arguments attendus

Où les paramètres sont...

$method

Le nom de la méthode, sous la forme d'une chaîne de caractères, à laquelle il faut appliquer la condition.

$args

Les argumetns sous la forme d'une liste. Les jokers peuvent être inclus de la même manière que pour setReturn(). Cet argument est optionnel pour expectOnce() et expectAtLeastOnce().

$timing

La seule marque dans le temps pour tester la condition. Le premier appel commence à zéro et le comptage se fait séparement sur chaque méthode.

$count

Le nombre d'appels attendu.

Si vous n'avez qu'un seul appel dans votre test, assurez vous d'utiliser expectOnce.
Utiliser $mocked->expectAt(0, 'method', 'args); tout seul ne permettra qu'à la méthode de ne jamais être appelée. Vérifier les arguements et le comptage total sont pour le moment indépendants. Ajouter une attente expectCallCount() quand vous utilisez expectAt() (dans le cas sans appel) est permis.

Comme les assertions à l'intérieur des scénarios de test, toutes ces attentes peuvent incorporer une surchage sur le message sous la forme d'un paramètre supplémentaire. Par ailleurs le message original peut être inclus dans la sortie avec "%s".