IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Bibliothèques et frameworks PHP Discussion :

PHPUnit avancé : patterns de tests [Tutoriel]


Sujet :

Bibliothèques et frameworks PHP

  1. #1
    Invité
    Invité(e)
    Par défaut PHPUnit avancé : patterns de tests
    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

  2. #2
    Membre émérite
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 448
    Points : 2 284
    Points
    2 284
    Par défaut
    super merci de l'article.

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    61
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Avril 2009
    Messages : 61
    Points : 109
    Points
    109
    Par défaut
    Merci pour cet article très intéressant et surtout très pro!

  4. #4
    Rédacteur

    Profil pro
    Inscrit en
    Avril 2007
    Messages
    182
    Détails du profil
    Informations personnelles :
    Âge : 57
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Avril 2007
    Messages : 182
    Points : 1 853
    Points
    1 853
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    $this->stock[$nom] += abs((float)$prix);
    ainsi que
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    mon blog - mon site web

  5. #5
    Membre actif
    Avatar de foucha
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    121
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 121
    Points : 251
    Points
    251
    Par défaut
    Très très intéressant, et j'apprécie que ce soit en PHP !

    Merci
    ++
    Foucha.

    =========

    "du code propre c'est du code qui fait exactement ce qu'on croit que ça fait"

    Mes Articles DVP

  6. #6
    Invité
    Invité(e)
    Par défaut
    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

  7. #7
    Rédacteur

    Profil pro
    Inscrit en
    Avril 2007
    Messages
    182
    Détails du profil
    Informations personnelles :
    Âge : 57
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Avril 2007
    Messages : 182
    Points : 1 853
    Points
    1 853
    Par défaut
    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
    mon blog - mon site web

  8. #8
    Membre confirmé

    Inscrit en
    Septembre 2006
    Messages
    466
    Détails du profil
    Informations forums :
    Inscription : Septembre 2006
    Messages : 466
    Points : 515
    Points
    515
    Par défaut
    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

  9. #9
    Membre confirmé
    Avatar de FMaz
    Inscrit en
    Mars 2005
    Messages
    643
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 643
    Points : 640
    Points
    640
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 !

  10. #10
    Invité
    Invité(e)
    Par défaut
    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

Discussions similaires

  1. [Hudson] PHPunit Infos dans des tests « En succès »
    Par overkris dans le forum Intégration Continue
    Réponses: 2
    Dernier message: 29/10/2010, 18h48

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo