C'est du joli travail, j'adhère vraiment de plus en plus à ton mini-framework !

Quelques petites choses supplémentaires histoire de l'améliorer :

Dans la classe TestUnitaire, il te manque une fonction fail($message) qui permet de forcer le log à afficher un statut de fail sur le test en cours. C'est utilisé si on sort d'un simple assert :

if ($cond1 != $val && ($cond2 > $max || $cond2 < $min) fail("valeur aux limites);

D'ailleurs tu peux aussi lors de la génération des classes la rajouter (dans TestManager --> write_method : dans le corp de la méthode rajoutes :
$this->fail('Not implemented yet');

Dans le TestManager toujours, dans la méthode launch, fais un try catch sur l'exécution du test car les erreurs peuvent faire arrêter le test sinon, à logguer aussi dans le statut d'exécution.

Il ne manque plus grand chose à ta librairie, juste le packaging : un nom de projet, de la phpdoc sur les classes, un repository SVN et un site web (sourceforge est pas mal pour ce genre de choses). Si tu le mets sous GIT (https://github.com/) je vais peut-être en faire un fork :)

En tout cas merci de partager ton source, je vais surement l'utiliser :)

Bonne prog et tiens-nous au courant,
akh

C'est très bien, pour les setup et teardown - ça permet de se créer un contexte de tests ISO et mieux cloisonnés - important pour éviter les effets de bords de certains tests - petit bémol quand tu sort du scope du $this le cloisonnement n'est plus géré ($_REQUEST, $_SESSION, $GLOBALS ... appels vers des variables statiques) - mais ce type d'effet de bord est très minime.

Parcontre je ne mettrait pas les appels (setUp, test_..., tearDown) dans l'instanciation de la classe de test mais je ferais une classe TestManager à part, qui elle lencerait par exemple les tests sur une classe, ou sur un ensemble de classes. L'objet devrait à mon sens être reconstruit à chaque execution de test.

La classe de log c'est bien la class Débug que tu as actuellement, elle devrait effectivement être en mode singleton et juste stocker les infos.

La classe TestManager s'occuperait de dumper les résultats en fin de test par exemple. Pour la structure de débug, faudrait rajouter un niveau de log sur la classe en cours d'execution vu que c'est multi-classes.

J'utiliserais les classes de Reflection dans le TestManager pour gérer les annotations de documentation, histoire d'associer des commentaires aux fonctions testées et de les affichers dans les résultats.

NB : Un truc utile dans le TestManager est de pouvoir générer un fichier de test unitaire en lui passant en argument un nom de classe.

Si tu peux faire le tout en moins de 1000 lignes de codes, tu tiens un framework de tests unitaires complet et surtout facile d'utilisation.

:) bon courrage

Bonjour Pierre,

Un source très intéressant, les asserts en PHP sont assez peu utilisés donc c'est très instructif d'en voire un exemple.

Le code est très simple et j'aime ton approche KISS et justifiant le fait de ne pas passer par un framework de type PHPUnit.

Je commence par un point "obscur" sur le :

$this->_return[$this->iNbError][$config] = $$config; la liste des clés étant limitée par la signature de la fonction je ne vois pas trop l'intérêt de cette boucle.

Un simple code aurait pû suffire :

$this->_return[] = array(
  'line' => $line,
  'code' => $code
);

--> Pour faire un peu d'optimisations :) <--

Dans la classe Debug :

- Les variables iNbError, et _config n'ont pas besoin d'exister
A la place de iNbError, tu peux utiliser : sizeof($this->_return)

- De la manière dont tu as écrit ta classe Debug n'est pas un singleton, donc soit supprimer oInstance soit en faire un vrai : cf partie PHP 5 : http://fr.wikipedia.org/wiki/Singleton_%28patron_de_conception%29

Dans la classe TestUnitaire :

- J'aurais plutôt mis l'instanciation des asserts dans les DEBUG

- Pour permettre d'instancier les asserts à partir des DEBUG j'aurais éventuellement loggué dans Debug toutes les assertions, ainsi j'aurais également eu le log de tout ce qui est OK.

Sur le principe, il me manque un élément, c'est le contexte d'implémentation des tests unitaires : je présume qu'actuellement on doit le fait en bloc dans le construct. Au passage dans la classe TestUnitaire ton __construct devrait être final public pour éviter les effets de bords de l'héritage.

* Y'à t'il moyen d'avoir un cloisonnement des contextes avec plusieurs fonctions ...
* Si dans une exécution on veut exécuter plusieurs classes de tests à la fois ...

Si tu règle ces petits points je pense que ta classe à vraiment un bon potentiel car c'est pas vraiment intéressant de déployer, configurer et customiser PHPUnit, alors que ton code serait beaucoup plus facilement adaptable.

Bonne continuation,
akh

J'ai hâte de lire ton tuto car je suis un peu imperméable aux formules mathématiques et théoriques et le site de Levee ne m'a pas plus aidé. Je trouve que la théorie des ensembles embrouille plus que n'explique, un bon tuto et une bonne dose de vulgarisation ne ferais pas de mal :))) surtout qu'après quelques recherches acharnées sur google j'ai rien trouvé de convaincant.

Bon courage pour ton tuto et merci pour cette source :)

Petite correction à la fin de ton code, faut utiliser NodeParser au lieu de XMLParser.

En lisant le code je me rends compte que le buffer initialement utilisé est tronqué par son début à chaque itération (unbufferize), cela ne risque pas sur des gros buffers de ralentir le parsing ? Y'à t'il une raison pour laquelle on ne pourrait pas tout simplement utiliser une boucle et itérer sur un curseur qui avance sur le texte ?

Autre point, c'est que l'accès au buffer se fait de manière statique ce qui ne devrait pas trop être dérangeant, mais je me demandais pourquoi ne pas avoir utilisé des instances d'objets, ce serait la même conso mémoire, avec la possibilité de créer plusieurs instances chacune ayant son contexte ...

Sinon j'adore le côté simple ... mais j'aurais fait une classe reader à part de la classe qui parse (cela permettrait de lire un buffer ou un fichier selon le reader utilisé).

Je viens de lire un article wiki sur le sujet, je ne suis pas pour autant plus avancé ... pourrais-tu revenir un peu sur le principe de fonctionnement des parseurs LL car à priori ils ont l'air assez puissants ...

RIEN QU'UN MOT : J'ADORE !!!

J'ai bossé sur un parseur mais j'ai fait l'implémentation de manière intuitive, et après quelques refactoring je suis tombé sur quelque chose d'assez similaire, mais un peu trop lourd à mon sens.

Je l'essaye et je reviens pour te faire un retour, en tout cas merci pour ce code.

Le REST (Api AJAX) est à la mode ces derniers temps et c'est très simple de comprendre le pk, c'est tout simplement plus compatible contrairement à SOAP...(je suis pas trop d'accord avec lefauve sur le manque d'utilité d'une classe exploitant REST plutôt que du SOAP)

Pour le côté PHP (alors que REST semble que pour JavaScript) ça se justifier, car même si une alternative SOAP existe, c'est plus sympa de faire un file_get_contents sur une URL avec des paramètres en GET plutôt que d'utiliser des librairies SOAP qui ne sont pas distribuées par défaut sur toutes les versions...

J'insiste un peu sur cURL mais dommage de l'avoir utilisé forçant à avoir cette librairie, et le côté obscur de REST étant, vu que c'est moins formalisé je spaghéttise mon code ... les retours JSON devraient être toujours encapsulés dans des classes spécifiques ...

Petit conseil pour rendre ta librairie plus compatible avec tout genre de config : je te conseillerais d'oublier cUrl et d'utiliser un simple fopen sur l'URL ...

Sinon à mon avis il te manque une classe stockant le résultat de retour et dans google il te faudrait une fonction privée pour gérer le retour php et google...

bonne continuation,
akh

Oui, effectivement je viens de télécharger et voir le sdk red 1.1, ce qui est bien en SOAP c'est l'aspect orienté objet de ses wrappers, et une api REST devrait à mon sens également être orientée objet car sinon le code deviendra vite brouillon ...

Pour certaines api (du moins celle que j'ai testé) le json n'est pas implémenté (http://ws.red.sfr.fr/red-ws/red-b2c/resources/event/consume?ResponseType=json&token=81e3d203dd52a852fa986624c718929c) et pour de l'ajax/javascript c'est quand même plus sympa à parser (surtout que REST existe à mon sens prioritairement pour ce genre de language)

Sinon après un tour sur les différentes API, c'est franchement top, y'à moyen de se faire plaisir, parcontre ça reste un peu cher si ce n'est pas à but lucratif :)

ps : 10/10 pour les apis sfr :)), et pi j'aime bien l'idée de SFR de venir exposer ses travaux sur ce réseau opensource :)

Pas mal du tout, dommage que le code ne soit pas facilement modifiable et ré-utilisable, mais l'idée est tellement bien que j'en ait refait une version plus propre :
http://www.phpcs.com/codes/CLASSE-WIKILOC_52878.aspx

Etonnant ... SFR ne donne pas ses consommateurs d'api en PHP ?