Pour les besoins de l'AFUP, je dois me mettre un peu à SimpleTest (j'ai plus l'habitude sur PHPUnit). Je n'ai pas trouvé de channel PEAR (a priori) fournissant un package installable via PEAR de SimpleTest et fournissant l'outil en ligne de commande (comme peux le proposer PHPUnit ou d'autres outils). Je vous propose donc celui de mon cru...
Tag - test unitaire
jeudi, février 25 2010
SimpleTest, installation via mon PEAR
Par Olivier Hoareau le jeudi, février 25 2010, 17:18 - Outillage
mardi, novembre 17 2009
Session "Oui ! PHP est industriel !" au forum PHP 2009 @Paris
Par Olivier Hoareau le mardi, novembre 17 2009, 11:33 - Evènements
Le forum PHP 2009 de Paris s'est déroulé la semaine dernière, je vous livre le support de session que nous avons utilisé avec Damien Seguy à l'occasion de la présentation de notre session sur l'industrialisation en PHP.
lundi, septembre 28 2009
PHP : Une plateforme industrialisable au service de l'Agilité
Par Olivier Hoareau le lundi, septembre 28 2009, 19:51 - Méthodologie
Je publie sur slideshare une version refactorée d'une présentation draft que j'avais réalisé il y a quelques mois pour l'Université du S.I avant de préférer avec Damien Seguy une version plus light... Au programme, PHP et Agilité, encore et toujours ;)
samedi, septembre 26 2009
Test unitaire: comment bouchonner ?
Par Olivier Hoareau le samedi, septembre 26 2009, 16:59 - Méthodologie
L'exécution d'un test unitaire nécessite en règle générale la mise en place de bouchon (mock en anglais) qui permettent de simuler les appels systèmes ou d'api sous jacent.
En effet, il peut être difficile de tester une partie de votre code qui a des impacts sur le système externe (enregistrement sur disque, appels réseaux / webservices, stockage mémoire vive, appels base de données...), le principe du bouchon est alors bien pratique pour tester la logique sans déclencher toutes les opérations.
lundi, août 10 2009
Tests Unitaires : ma philosophie via un exemple
Par Olivier Hoareau le lundi, août 10 2009, 08:38 - Méthodologie
Je vois souvent des tests dit unitaires chez mes clients, mais qui se connectent à la base de données, font des requêtes réseaux...
Voici une petite présentation de ce que personnellement j'appelle tests unitaires, par l'exemple.
Commentaires récents
Plutot qu'écrire du code pour les Mock, PHPUnit a développé un système de bouchon assez puissant.
Voir la fonction getMock
Justement à propos de :
il manque un test (non unitaire cette fois-ci) qui nous permet de vérifier
Quelle serait sa forme idéale ? Implémentation, méthode, utilisation ?
@Bruno: un début de réponse dans mon post : http://blog.phppro.fr/?post/2009/08/14/Tests-d-integration-quezako
@jsh : tout à fait d'accord avec la présence de cette fonctionnalité intéressante de PHPUnit, pour ma part je préfère réaliser mes mocks moi même car sinon je ne peux pas utiliser de mock en dehors de mes tests unitaires, hors cela peut être intéressant d'utiliser un mock à certains moment du développement (au début du développement d'un webservices par exemple), ou bien dans un autre contexte d'appel que phpunit. D'autre part, je trouve le mécanisme de gestion de la pile d'appel assez verbeux à écrire pour le mock, et je préfère la notion de pile à la "addExpectedResult", plus brute mais plus simple. Mais la fonctionnalité reste intéressante ;)
Complément d'information posté sur le blog de Clochix (http://www.clochix.net/post/2009/09...) concernant l'utilisation des fonctionnalité Mock de PHPUnit:
Pour ma part, j'évite de l'utiliser (i.e. la fonctionnalité Mock de PHPUnit) car je souhaite rester indépendant d'un quelconque framework lors de mon développement.
Les fonctionnalités Mock de PHPUnit sont très intéressantes, elles ont cependant de mon point de vue un défaut majeure dans l'utilisation que je fais des mocks. En effet, lorsque je développe j'utilise la version "mock" de mes classes (adapter) dans mon code tant que je n'ai pas développé la version native (standard). Cela me permet de prototyper / présenter rapidement les fonctionnalités "statiques" de mes développements et de "débrancher" lorsque je suis prêt le mock pour mettre la vraie implémentation (imaginez que je développe un webservice et que je doive rapidement fournir une version de mon webservice pour des consommateurs qui seraient "impatients"). Le problème avec le framework PHPUnit est qu'il n'est pas adapté a priori pour une utilisation en dehors des tests unitaires.
autre part les mocks peuvent être utiles dans d'autres cas encore que les tests unitaires et celui que je décris, par exemple certains tests d'intégration qui porte sur d'autres zones du code... même remarque dans ce cas.
Et vous quels sont vos pratiques pour mettre en place des bouchons dans les cas autres que les tests unitaires ?
Bonjour,
j'ai trouvé le slide excellent. cela correspond pile poil à ce que j'aimerai mettre en place dans mon entreprise.
ce n'est pas facile mais j'y crois dur comme fer.
est-ce que tu as quelques conseils sur la manière de procéder ?
merci d'avances
@jacko972: envoie moi un email sur contact at phppro point fr en me décrivant ton contexte, tes problématiques et tes questions
Nous passons par le svn de SimpleTest (https://simpletest.svn.sourceforge....), tout "bêtement", ce qui nous permet d'avoir une propriété svn:externals dans le projet concerné et de mettre à jour simpletest facilement s'il y a lieu.
Vu qu'aucune configuration n'est nécéssaire au niveau de SimpleTest, la mise en oeuvre d'un autre outil ne s'est jamais fait sentir.