PHPUnit avancé : patterns de tests [Article]

[doctorrock]

Nous avons déjà compris le fonctionnement de PHPUnit et le principe des tests en développement PHP, au travers de l'article Développement piloté par les tests avec PHPUnit.
Nous allons à présent montrer les fonctionnalités avancées de PHPUnit notamment concernant les patterns de tests, Mock, Stub, Double, Spy ; nous verrons comment les mettre en place au travers d'un exemple simple et concret, et en quoi ces techniques peuvent rapidement devenir addictives.
Pour cela, il conviendra de rappeler les grands principes du développement logiciel orienté objet : SOLID.
Nous parlerons ensuite d'autres fonctionnalités PHPUnit propres au contexte des tests : sauvegarde des variables globales, sauvegarde du contexte statique, isolation des tests dans des processus distincts...

Article PHPUnit Avancé et patterns de tests

[kaymak]

super merci de l'article.

[Jean Meurtrier]

Merci pour cet article très intéressant et surtout très pro!

[Bruno Orsier]

Merci Julien pour cet article très intéressant. Nous l'avons utilisé comme support pour apprendre SOLID lors de l'un de nos dojos à Grenoble (CARA coding dojo). Nous avons utilisé aussi les principes avancés de Régis Médina.

Quelques points de ton article ont toutefois suscité des débats !

Par exemple la présentation de "Interface Segregation" dans l'article "Faites en sorte que vos objets ne se parlent pas directement, mais que chacun parle à une interface de l'autre" ne correspond pas bien à celle de Régis Médina "Les clients ne doivent pas être forcés de dépendre d'interfaces qu'ils n'utilisent pas."

L'exemple de l'article correspondrait plus à de l'inversion de dépendances (DIP), plutôt qu'à de la ségrégation d'interface.

Ensuite le D de SOLID correspond d'habitude plutôt à inversion de dépendances (DIP), plutôt qu'à l'injection de dépendances, non ? L'injection de dépendances est un outil (parmi d'autres) qui permet de respecter le principe de l'inversion de dépendances.

Plus au niveau du code, ton entité SessionStockage a nous a posé problème, car elle nous a paru avoir au moins deux responsabilités, à savoir le stockage, et le calcul du montant total du panier. Est-ce qu'il y avait une bonne raison de faire comme cela ? Cela nous semble violer le principe de responsabilité unique que justement tu invoques, et continue de maintenir une confusion entre les responsabilités de SessionStockage et Panier (et peut-être il y a une responsabilité non identifiée de Facturation).

Ce rôle un peu flou de SessionStockage apparaît aussi dans MockStockage, avec la duplication du code déjà présent dans SessionStockage, à savoir

Code :

$this->stock[$nom] += abs((float)$prix);

ainsi que

Code :

1
2
3
4
    public function total()
    {
        return array_sum($this->stock);
    }

Ces duplications de code semblent indiquer qu'il y a une responsabilité supplémentaire à factoriser. D'autre part elles affaiblissent beaucoup la valeur des tests, car ce qui est testé n'est pas exactement le code de production ! Enfin si on doit plus tard changer la logique métier de calcul du total (par exemple on a une réduction si on achète 2 fois le même article) il faudra toucher à la fois le code de production et le code de la doublure.

Enfin il nous est venu une question sur la classe Panier

Code :

1
2
3
4
5
6
7
8
9
10
11
class Panier
{
    protected $_stockage;
 
    public function __construct(Stockage $s = null)
    {
        if ($s == null) {
            $s = new SessionStockage("panier");
        }
        $this->setStockage($s);
    }

Pourquoi ce test sur null et la création dans ce cas de SessionStockage ? Cela maintient justement la dépendance que l'on voulait faire disparaître avec l'injection ?

Voilà les questions qui nous ont préoccupés !

Merci encore pour cet excellent sujet de discussion qui nous a bien occupés pendant 2H.

Bruno

[foucha]

Très très intéressant, et j'apprécie que ce soit en PHP !

Merci

[doctorrock]

Oui bon on sait tous ce qu'est la POO => un chemin vers la réflexion infinie.

J'aurai pu mieux faire, j'aurai pu creuser plus, mais je veux éviter (sans mauvais troll) "l'objetitte" de Java : une classe String ...
L'article doit rester clair et faire passer un feeling objet au lecteur.

Évidemment, chaque projet nécessite une réflexion personnalisée

[Bruno Orsier]

Oui, c'est sûr que ces principes peuvent être poussés très loin, au détriment de la clarté.

C'est juste qu'on se demandait si tu avais des raisons impérieuses pour aboutir au code proposé, vu qu'aucun de nous ne connaissait PHP...

Bruno

[rseM2]

Ton article est très intéressant et c'est pour cela qu'on l'a utilisé pour notre coding dojo. En retour, on voulait te faire des propositions si cela pouvait t'aider à l'améliorer.

Bruno a souligné plusieurs points qu'on n'a pas forcément compris : soit par manque de connaissances PHP, soit pour des choix de conception qu'on ne comprenait pas toujours (sans forcément parler de pinaillage à l'infini).

L'objectif n'étant pas de pointer d'éventuels points faibles mais plutôt de mieux comprendre pour s'améliorer.

Rémy

[FMaz]

J'étais en train de lire les articles quand j'ai remarqué qu'il semblait y avoir une erreur.

En effet, je ressors d'une conférence sur PHPUnit (mais pas celle donnée par Sebastian, malheureusement), et en comparant les exemples du tutoriel avec le contenu de la conférence, ainsi qu'avec la documentation en ligne sur phpunit.de, j'ai remarqué que les paramètre de assertEquals semble être inversé dans le tutoriel.

Au niveau du fonctionnement, ca ne semble rien briser, mais je crois qu'au niveau des utilisations avancé, et de l'optimisation, ou sinon tout simplement pour respecter les normes en vigueur, il peut être bien de préserver l'ordre règlementaire:

Code :

1
2
 
$this->assertEquals(<valeur de référence>, <valeur à tester>);

Voir:
http://www.phpunit.de/manual/current...r-phpunit.html


Ceci étant dit, je n'ai pas encore terminé ma lecture, et jusqu'à maintenant, ca me semble être une ressource extrèment intéressante ! Toute mes félicitation à l'auteur !

[doctorrock]

Merci pour ces corrections.

Pour les choix architecturaux, ce sont 10 ans d'expérience qui parlent (bon OK, 6ans en ce qui concerne PHP5), donc ça ne se justifie pas tellement...
Et puis il y a la clarté de l'article et son accessibilité à prendre en compte, ce n'est qu'un exemple pour un article dvp et en aucun cas une situation réelle