28 votes

Quel est l'état de la TDD et/ou de la BDD en PHP ?

Dans quelle mesure les tests sont-ils répandus, soutenus et développés dans le monde PHP ? Au même niveau que Java ? Au même niveau que Ruby/Rails ? J'ai cherché sur Google et j'ai trouvé que des cadres de test existent, mais je me demande s'ils sont largement utilisés.

Les principaux IDE PHP ont-ils des runners de test intégrés comme le font les outils Java d'Eclipse ou les outils Ruby/Rails de NetBeans ? Les tests sont-ils intégrés aux frameworks MVC de PHP, comme c'est le cas avec Rails ?

Je pose la question parce qu'un groupe où je travaille veut engager quelqu'un pour développer une application PHP pour eux. Je m'inquiète de la qualité et de la maintenance, car je pourrais être appelé à assurer le support de cette application.

43voto

Alan Storm Points 82442

Il existe au moins deux suites de test matures, autonomes et de style JUnit, nommées PHPUnit y SimpleTest respectivement.

En ce qui concerne les cadres MVC, Symfony a son propre cadre de test nommé chaux Code Igniter a un unit_test bibliothèque et CakePHP s'appuie sur le SimpleTest mentionné plus haut.

Je sais que Zend Studio a un support intégré pour les tests PHPUnit, et PHPUnit et SimpleTest ont tous deux des exécuteurs en ligne de commande, donc l'intégration dans n'importe quel workflow est possible.

Les outils sont là dans le monde PHP si un développeur veut en profiter, et les boutiques intelligentes en profitent.

Les réserves sont les plaintes habituelles de PHP. Il y a deux communautés PHP : PHP en tant que plateforme pour construire des logiciels, et PHP en tant que moyen d'interagir avec un serveur web, un navigateur web et une base de données pour produire des applications sur le web. Parmi les développeurs de logiciels, les tests unitaires et le TDD sont supportés et utilisés autant que sur n'importe quelle autre plateforme. Parmi les personnes "qui bricolent un tas de trucs que je ne comprends pas mais qui obtiennent quand même des résultats", c'est du jamais vu.

Il y a beaucoup de code PHP non-travaillé ou personnalisé autour duquel il est difficile d'obtenir un harnais de test utile. PHP se prête aussi facilement aux modèles qui dépendent de l'existence d'un environnement de navigateur pour fonctionner. Je n'ai pas d'autres preuves que mes propres observations, mais beaucoup d'ateliers PHP qui s'intéressent aux tests finissent par s'appuyer sur les tests d'acceptation (c'est-à-dire Selenium) comme substitut aux tests unitaires, aux tests en premier, etc.

Dans votre situation spécifique, faites passer un entretien au développeur que votre groupe va engager.

  1. Demandez-leur quel cadre de test unitaire ils utilisent

  2. Demandez-leur de décrire, en termes généraux, un exemple concret d'une situation où ils ont développé une nouvelle fonctionnalité et les tests qui l'accompagnent.

  3. Demandez-leur de décrire, en termes généraux, un exemple concret d'échec de leurs tests et ce qu'ils ont fait pour résoudre la situation.

Vous êtes moins intéressé par la situation spécifique qu'ils vont décrire et plus intéressé par le fait qu'ils sont à l'aise pour discuter de leurs connaissances sur les tests de code en général.

11voto

Rudy Lattae Points 674

Chaque fois que j'effectue le TDD d'un projet avec des outils de type XUnit, j'ai du mal à me mettre dans le bon sens. Je trouve que l'utilisation d'outils conçus pour le développement piloté par le comportement ou " Spécification par l'exemple " rend plus facile pour moi de faire le TDD correctement -- c'est-à-dire l'accent mis sur la conception, l'exposition de l'intention et l'utilisation de la technologie. la description du comportement dans des contextes spécifiques . Non de test.

Cela dit, j'aimerais vous présenter pecs dans la conversation. Extrait du fichier readme sur le site du projet.

pecs est une petite bibliothèque de développement orientée comportement pour PHP 5.3, à la RSpec ou JSpec.

Si vous avez utilisé JSpec ou mieux encore, Jasmine-BDD (pour JavaScript) le style pecs de description du comportement devrait être vraiment familier. Je trouve ce style idéal pour les spécifications au niveau des composants. Si vous cherchez un outil PHP pour les spécifications au niveau des fonctionnalités (histoires ou tests d'acceptation par les utilisateurs), pensez à Behat .

Pour en revenir à pecs, voici un exemple tiré du site du projet pecs :

describe("Bowling", function() {
  it("should score 0 for a gutter game", function() {
    $bowling = new Bowling();
    for ($i=0; $i < 20; $i++) {
      $bowling->hit(0);
    }
    expect($bowling->score)->to_equal(0);
  });
});

Oui, c'est une spécification PHP. En regardant les sources de pecs, il semble que l'auteur ait réussi à faire cela en utilisant les nouvelles tendances de PHP 5.3+, les lambdas et les fermetures. Je suppose donc que cela signifie que vous ne pouvez pas utiliser pecs dans un projet basé sur PHP < 5.3 (juste pour info).

De plus, pecs n'est pas aussi mature que PHPUnit ou SimpleTest. Cependant, je pense que les partisans de BDD dans la communauté PHP devraient soutenir la croissance d'outils comme pecs qui encouragent la "spécification par l'exemple" ou BDD sans la confusion apportée par l'utilisation d'outils de test XUnit.

En ce moment, je travaille davantage en Python qu'en PHP. Cependant, la prochaine fois que j'entreprendrai un projet PHP, je serai extrêmement heureux de disposer d'un outil mature, soutenu par la communauté, comme pecs, pour élaborer les spécifications du logiciel.

5voto

branchgabriel Points 2436

J'ai eu une expérience incroyable avec Behat / Mink. http://behat.org

Je suis d'accord avec les autres, le php en tant que plateforme de test unitaire n'est pas une expérience amusante. Le BDD est la meilleure façon de procéder si vous utilisez un framework php.

La plus grosse pierre d'achoppement a été de comprendre que composer est un outil de construction de repo, mais nous avons pu utiliser Behat Mink Selenium Webdriver standalone server jar comme un outil de conception et de test de régression étonnant. Nous avions l'habitude d'exécuter notre suite de tests de régression contre notre application CakePHP sur un serveur Jenkins, mais il s'est avéré qu'il n'était pas assez rapide en termes d'échec.

Maintenant, notre flux de travail se déroule comme suit : Créer une histoire dans gherkin affiner l'histoire écrire la fonctionnalité et le stub pour toute nouvelle étape défs commencer à coder la solution php à tester A la fin, nous avons une fonctionnalité fonctionnelle ou une correction de bug avec un test bdd qui la couvre.

Nous avons installé une VM Ubuntu avec une configuration Behat fonctionnelle et l'avons copiée sur chaque poste de travail. Nous l'avons intégré dans notre processus. Il nous suffit de télécharger les changements, de faire des tests et de commencer à coder de nouvelles choses.

Nous avons écrit un shell script pour exécuter automatiquement les dumps mysql et les charger avant chaque fonctionnalité, ce qui a fait de la refactorisation du code un jeu d'enfant.

La classe Mink WebAssert vous donne toutes les assertions dont vous avez besoin pour valider un comportement. Les classes session ordinaire / CommonContext sont parfaites pour utiliser css ou xpath.

J'ai déjà utilisé Capybara / WebDriver avec des projets Java et Rails et j'ai trouvé que les frais d'installation / la courbe d'apprentissage étaient trop élevés par rapport à Behat.

4voto

chuckg Points 2624

En plus des bibliothèques et des cadres de travail qui Alan a déjà mentionné, vous pouvez utiliser Apache::Test de mod_perl, que j'utilise comme un harnais. Il me permet d'intégrer très simplement des tests dans mon processus de publication. Le harnais utilise TAP (Test Anything Protocol) pour déterminer si les tests réussissent ou échouent, en utilisant des bibliothèques telles que Test::Simple ou Test::More ( Perl y PHP ).

Apache::Test est prêt à écrire des tests en Perl et en PHP. Dans mes propres projets, il m'a fallu un peu de un peu d'astuce et beaucoup de lecture pour le faire fonctionner, mais une implémentation de Test::More en PHP est intégré au harnais. L'exécution de tous les tests écrits à la fois en PHP et en Perl se fait par le biais d'une seule commande et tout échec en cours de route est capturé par Apache::Test, en notant du mieux qu'il peut ce qui s'est mal passé.

Ce qui est génial dans tout cela, c'est que vous pouvez même utiliser PHPUnit ou Simple-Test à côté des deux frameworks de test précédents. En exécutant les tests dans chaque bibliothèque respective, vous pouvez utiliser l'implémentation PHP de Test::More (ou même Perl en testant stdout) et renvoyer le TAP pour que votre harnais l'interprète.

Veillez à lire le Apache::Test et la documentation Guide mod_perl pour l'exécution d'Apache::Test . De plus, j'ai trouvé l'article aquí une aide précieuse.

À titre d'exemple rapide, vous pouvez configurer un test en Perl en quelques lignes de code qui va parcourir toutes les pages de votre site (qui ont des liens) et vérifier tous les résultats dans ' 200 OK et n'ont pas d'erreurs d'analyse :

#!perl

use strict;
use warnings;

use Apache::Test qw(:withtestmore);
use Apache::TestRequest;
use Test::More;
use Test::WWW::Mechanize;
use WWW::CheckSite::Validator;
use WWW::CheckSite::Spider;

plan 'no_plan';

my $config = Apache::Test::config();
my $host = "http://". Apache::TestRequest::hostport($config) || '';

my $s = WWW::CheckSite::Spider->new(
    uri => $host,
    ua_class => 'Test::WWW::Mechanize',
);
my $m = $s->current_agent;

while (my $page = $s->get_page) {
    is($m->status(), "200", $m->uri() ." retrieved successfully.");
    $m->content_lacks("Parse Error", $m->uri() ." does not contain syntax errors.");
}

3voto

Kzqai Points 7484

Sur un projet antérieur, j'ai utilisé PHPUnit, et il m'a laissé sur ma faim. PHPUnit + exécution des tests en ligne de commande, font que l'on passe trop de temps à coder les tests, ce n'est pas assez rapide, et cela semble vraiment contraindre le style du code d'une manière que je n'aime pas (les objets sont plus faciles à tester, donc cela semble favoriser les objets).

Selenium est une solution dont nous avons parlé mais que nous n'avons jamais pu mettre en œuvre, et je pense que nous aurions vraiment bénéficié de ce type de tests au niveau des résultats.

Sur ce dernier projet, le programmeur principal a adopté une approche de programmation plus fonctionnelle au fur et à mesure de la révision du logiciel. Lorsque j'ai mentionné que j'aimerais coder via TDD, il a élaboré en un jour ou moins une solution personnalisée que je considère comme aussi efficace que PHPUnit. En outre, il m'a vraiment ouvert les yeux sur la question de la programmation orientée objet par rapport à la programmation fonctionnelle.

Premier projet, parti de zéro, à la base, codage orienté objet, grand cadre de test unitaire, il est devenu monolithique et s'est enlisé rapidement. Deuxième projet, un logiciel CMS bien établi avec une histoire de 5 ans et un vieux code, mais un paradigme de programmation fonctionnelle et un cadre de test simple (nous avons en fait souvent utilisé php assert) l'ont rendu plus simple au lieu de le rendre plus complexe.

Le deuxième projet, lui aussi, n'est jamais arrivé au point de mettre en œuvre Selenium (et je pense toujours que cela serait bénéfique), mais l'approche de programmation fonctionnelle a facilité la gestion des tests en code.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X