Ainsi, elle ne fournit aucune information sur la signification des valeurs du tableau renvoyé par xdebug_get_code_coverage(), notamment lorsque la couverture de code a été demandée via xdebug_start_code_coverage(XDEBUG_CC_UNUSED | XDEBUG_CC_DEAD_CODE).
Pour l'exemple, voici un tableau pouvant être retourné par xdebug_get_code_coverage() :
array(
'/path/to/file' => array(
5 => int -1
6 => int -1
7 => int -1
9 => int -2
10 => int -1
11 => int 1
12 => int 1
13 => int -2
15 => int 1
16 => int -1
18 => int -1
)
)
S'il est relativement évident que les clefs correspondent aux numéros des lignes du fichiers, les valeurs -2, -1 et 1 m'ont laissé dans l'expectative la plus complète.
J'ai donc demandé les informations nécessaires à Derick Rethans, l'auteur de Xdebug, via IRC, et voici les explications manquantes :
- Une valeur à -2 indique que la ligne correspondante contient du code mort, c'est à dire qu'il ne sera jamais exécuté par PHP, comme par exemple une accolade fermante après un appel à l'instruction
return. - Une valeur à -1 indique que la ligne correspondante contient du code exécutable, mais qu'elle n'a pas été exécutée.
- Une valeur à 1 indique que la ligne correspondante a été exécutée.
Évidemment, la documentation de Xdebug devrit être prochainement mise à jour avec ces informations.
Et pour ceux qui se poserait la question, je n'ai encore aucune explication au sujet du fait qu'un appel à require('php://temp') empêche PHPUnit de faire son rapport de couverture de code correctement.
5 réactions
1 De Guile - 07/12/2010, 19:01
Je vais poser la question du gars qui sait pas quoi te répondre mais qui veut à tout prix te donner une réponse en te posant une question (???) : à quoi ça te sert réellement de faire require('php://temp') ? Tu ne pourrais pas faire autrement?
Bon à part ça j'ai bien conscience que ça ne t'avancera pas
2 De mageekguy - 08/12/2010, 00:00
@Guile : Je l'attendais celle-là :).
Plus sérieusement, je fais cela dans le cadre d'un test unitaire, afin de ne pas à avoir à inclure via
require()un fichier qui pourrait contenir des choses qui ne m'importe aucunement dans le cadre de mon test, voir même qui pourraient poser problème.Cette méthode m'évite également de mon système de fichiers avec un fichier vide qui ne me sert que dans le cas de ce test.
Bref, cette façon de faire, très peu orthodoxe je le reconnais, me permet d'avoir un test totalement indépendant du reste du monde.
Et c'est discutable à l'infini, et c'est pourquoi je ne rentrerais pas plus dans ce débat.
3 De windu.2b - 08/12/2010, 04:23
Et créer / détruire un fichier avec setUpBeforeClass() / tearDownAfterClass() ?
(ou setUp() / tearDown() si c'est nécessaire pour chaque test)
Ainsi, pas de fichier qui traine vu qu'il est détruit à la fin du test, et pas de pb avec "php://temp" (ce qui ne nous dit toujours pas où se situe le pb à utiliser ce fichier, certes...)
4 De Guile - 08/12/2010, 09:30
Ce dont j'ai peur c'est que ce wrapper est très particulier. As-tu essayé avec un autre wrapper ?
5 De mageekguy - 08/12/2010, 10:13
@windu.2b : C'est effectivement une solution mais elle crée une dépendance envers le système de fichier dont je souhaiterais me passer.
Le système de fichier peut être plein (plus d'inode, plus de place, etc), si les tests plantent, le nettoyage n'est pas forcément fait, il faut donc coder un garbage collector, si des tests sont exécutés en paralléle, ça peut poser des problèmes de lock, bref, c'est beaucoup plus de contraintes qu'un simple appel à php://temp.