Tag - service
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
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.
vendredi, septembre 11 2009
Service/Adapter : mes adapters sont trop gros mon capitaine !
Par Olivier Hoareau le vendredi, septembre 11 2009, 15:17 - Méthodologie
Si vous implémentez le pattern Adapter, ou bien si vous suivez mes posts, vous avez entendu parler de la notion d'Adapter. Mon point de vue sur la question est qu'ils doivent être minimals (1 à 2 lignes par méthodes, aucune logique autre que l'appel à une méthode native php / extension). On arrive alors de temps en temps à une problématique : les adapters ont tendance à vouloir "grossir", quand on veux "généraliser" la logique dans le service (et qu'on relègue l'implémentation dans l'adapter). La contrainte des 1 à 2 lignes est alors difficile à respecter... ou presque !
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.
mardi, avril 7 2009
Constuire une librairie "maison" : ou comment capitaliser à moyen terme
Par Olivier Hoareau le mardi, avril 7 2009, 14:53 - Méthodologie
Vous avez déjà développé des dizaines de milliers de ligne de code.
Vous avez déjà contribué à plusieurs (2, 5, 10 ...) projets d'applications PHP dans votre entreprise.
Vous avez déjà, comme moi, eu ce sentiment quand vous étiez sur le développement d'un morceau de code, que vous aviez déjà codé cela une fois, mais impossible de vous souvenir "comment" et "où" retrouver le code.
"Ah, si j'avais un listing bien organisé de tout ce que j'ai codé rangé par fonctionnalité..."
mercredi, novembre 5 2008
Pattern Factory : Ou comment faire tout en 1 ligne
Par Olivier Hoareau le mercredi, novembre 5 2008, 08:00 - Méthodologie
Vous révez de ça :
<?php
$service = new MonService()
-> setConfig(...)
-> setAdapter(...)
-> setModel(...)
-> process();
...
Commentaires récents
C'est typiquement le genre de syntaxe dont on est très friand dans Copix :-)
Il faut avouer que cela simplifie l'écriture.... par contre on se retrouve vite avec des syntaxes compact dont il faut connaître la signification :-)
_dao ('MaTable')->findBy (
_daoSp ()->addCondition ('champ', '=', $valeur)
->addCondition ('champ2', '=', $valeur2)
->orderBy ('champ3')
)
Ce qui ici signifie : Je vais récupérer dans ma table "MaTable", grâce à un "Data Access Object", les enregistrement qui correspondent aux paramètres de recherches (daoSP = Data Access Object Search Params) ....
Le plus proche de l'exemple serait la fabrique de classe, utilisée de la sorte :
_class ('classId')
...qui retourne un new 'ClassId' (en plus d'inclure le fichier en question grâce à un système d'autoload).
J'aime assez aussi la possibilité de faire un raccourcis pour obtenir des singletons de ces objets, avec par exemple
_ioClass ('classId');// (instance of class) qui retournera systématiquement la même instance de la classe 'classId'.
En tout cas c'est sûr, le nested call de PHP 5 est pour moi une grande nouveauté par rapport à la version 4 :-)
Merci beaucoup pour ce petit billet très instructif ;)
Mais comment n'y ai je pas pensé avant ?
Si le concept de packages pour PHP vous intéresse, jetez un coup d'oeil à http://webappkit.net
Il s'agit un système de paquets pour PHP, qui facilite la gestion des dépendances entre librairies et offre également une interface d'administration permettant de visualiser le tout et d'executer les tests unitaires.
Et bien sûr, c'est open source et quelques librairies sont déjà fournies.
Merci pour l'information sur webappkit !
Je testerais dès que possible.
Quelle est la particularité par rapport au système de gestion de dépendances et de packaging de PEAR ?
Olivier
PEAR s'installe au niveau système et ne gère que des librairies. Webappkit s'installe au niveau application web (simple dezippage), de telle manière qu'une appli construite sur Webappkit peut être entièrement installée via FTP.
De même, l'interface d'administration est une page web qui à terme permettra d'installer les librairies par upload de fichier zip. Pour l'instant elle permet de visualiser les tests, vérifier les dépendances, l'intégrité des paquets etc.
En outre, les paquets sont accessibles sous forme d'objets dont la classe est extensible, et auquels on peut adjoindre des objets services issus d'autres paquets. Un paquet peut ainsi contenir d'autres types de ressource que des scripts PHP, tel que des templates, etc. Ceci permet d'avoir une application complete sous forme de paquet.
Je ferai une nouvelle release (0.13) prochainement (une a deux semaines).
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 ?