J’ai repris le développement des tests unitaires avec Atoum (qu’avait mis en place nikrou à l’époque), en commençant par ceux de Clearbricks, laissés en plan depuis des années — oui, je sais, c’est pas bien, mais … :-) — profitant d’une revue de cette librairie qui sert de fondation à Dotclear[1], et il y a du boulot, dont le premier a été de mettre à jour mon environnement de test et de corriger les-dits tests ; eh oui, le code a bougé et pas les tests qui vont avec, c’est ballot.
Une fois les quelques tests passés avec succès, un joli 100% ça fait toujours plaisir, j’ai testé la couverture de code, qui permet de vérifier que toutes les lignes de code sont testées :
Vous voyez qu’il y a encore du boulot pour couvrir tout ce qui existe, et quand je dis ce qui existe ça concerne uniquement ce qui est testé, qui reste encore très minoritaire par rapport au code fourni par Clearbricks.
On peut aussi activer un rapport supplémentaire concernant les branches (tests) et les chemins (code dépendant des tests) parcourus qui restent encore plus minoritaires :
Ensuite on peut parcourir chacune des classes testées :
Et ainsi aller jusqu’au code testé d’une des méthodes/fonctions :
L’image ci-dessus montre également qu’on ne peut pas vraiment tout tester, surtout avec du code qui est uniquement utilisé lorsqu’il est exécuté sur un environnement « dégradé ». J’entends par dégradé un environnement où certaines fonctionnalités inclues de base ont été désactivées alors qu’elles sont utiles, ou que la version minimale attendue est supérieure à celle utilisée pour les tests.
Ici la fonction hmac() fait appel à la fonction hmac_legacy() que si la fonction PHP standard (depuis la version 5.1.2) hash_hmac() n’est pas disponible, ce qui est habituellement pas le cas et qui explique que cette ligne de code n’a pas été « testée » par les tests unitaires.
Par contre, pour pouvoir tester que cette fonction de secours, hmac_legacy() fait correctement son boulot, j’ai sorti son code de la fonction hmac() afin d’en faire une fonction autonome. Ça permet de tester le maximum de chose, sans pour autant parvenir à une couverture de code égale à 100%.
Après de posent quelques questions philosophiques :
- Est-ce qu’on doit modifier le code source pour approcher une couverture maximale ?
- Est-ce qu’au contraire il convient de rester raisonnable et de privilégier l’efficacité du code ?
- Est-ce qu’un test, une fois qu’il a tourné correctement et donc implique qu’une fonction renvoie en permanence un état connu, peut-il être modifié pour refléter la modification de comportement d’une fonction ?
- Voire même est-ce qu’une fonction, une fois testée et « validée », doit rester ad vitam aeternam telle qu’elle existe (en terme de comportement) ?
- …
Tout ça pour dire que ces simples tests, même s’ils rendent le code plus robuste, n’en demeurent pas moins qu’un témoin sujet à caution, d’une part, et que d’autre part ils ne couvrent pas l’aspect fonctionnel — est-ce que l’application a le comportement attendu ?
Mais pour les tests fonctionnels, il y a aussi des solutions, Behat par exemple, mais j’y reviendrai plus tard, et ça sera côté Dotclear :-)
En attendant c’est assez rigolo à faire et à tester, en tout cas pour l’instant, mais y’en a pour des heures et des heures d’écriture de test, et je ne parle que de Clearbricks, alors imaginez pour Dotclear ; donc ça sera probablement encore un peu jusqu’à ce que je me lasse, puis j’y reviendrai de temps en temps…
Note
[1] Le moteur de template de Dotclear, c’est Clearbricks, la syntaxe wiki, aussi, l’interface avec les bases de données, idem …
1 De Pablo -
C’est dommage que tu travailles tout seul sur ces tests (et sur tout le reste :-| ), je trouve ; non seulement à cause de la quantité de boulot que cela représente, bien sûr : mais aussi à cause de tout ton savoir, et de ton savoir faire, qui ne sont partagés que de façon très sommaire ici et là ; et réciproquement, à cause de l’absence hypothétique de tout ce que pourraient t’apporter d’éventuels collaborateurs (pour ne pas parler de comment ça enrichirait le projet DC lui-même…). Au moins on sent que ça t’amuse et que ça t’enrichit, toi, un peu… (Réflexion inutile, mais bon). Bon courage !
2 De Franck -
Merci pour ton soutien Pablo !
3 De Nicolas -
Super. Bravo de continuer ce que j’avais essayé de faire. C’est un énorme chantier.
p.s: il y a une coquille dans le README c’est -ebpc et non pas -epbc
Sinon je n’arrive pas à sortir le html de la couverture de code. Je dois rater un truc.
4 De Franck -
Je vais corriger le README, merci pour le signalement.
Pour la couverture de code il te faut XDebug 2.3 mini, sinon t’auras rien ; ça vient peut-être de ça ?