Pour cela nous utiliseront le plugin Hudson Emma pour l’affichage dans Hudson, ainsi que le plugin symfony agEmmaCoverageReport pour générer le fichier xml au format emma.
Le format « emma » est à la basée utilisé en java, plus d’infos sur le site du projet.

Utilisation de la tache de génération du rapport xml

L’extension xdebug doit être installée (mais pas forcément activée).

Les fichiers testés sont trouvés en utilisant l’autoload, les fichiers de tests doivent être nommés de la façon suivante : nomDeLaClasseTesteeTest.php, par exemple le classe « qualifactCellFormatterEuro » aura pour fichier de test « qualifactCellFormatterEuroTest.php ».

Voyons tout d’abord comment fonctionne la génération du fichier xml de rapport :

Si xdebug est activé par défaut :

./symfony ecr:report --xml=cheminOuSauverLeXml.xml

Mais sur le serveur d’intégration cela n’est probablement pas le cas, et il serait
gênant d’avoir à l’activer pour les autres tests alors que qu’il est seulement utilisé pour le coverage.
Pour cela on peut indiquer à la tache le chemin ou se situe l’extension xdebug (par exemple sur une Mandriva il se situe ici : « /usr/lib/php/extensions/xdebug.so »). La tâche sera alors appelée de cette façon.

./symfony ecr:report --xml=cheminOuSauverLeXml.xml --xdebug-extension-path=/usr/lib/php/extensions/xdebug.so

Intégration dans Hudson CI

Création et configuration du job

• Dans le menu de gauche : « Nouvelle Tache »
• Cliquez sur « Construire un projet free-style »
• Donnez un nom au job
• Entrez alors l’url du dépôt
• Après checkout nous voulons lancer les tests unitaires ainsi que la tache créant

le rapport de coverage, nous allons donc ajouter une étape au build. Celle ci sera de
type « Executer un script shell »

• Dans la liste des commandes nous allons donc lancer les tests et le coverage de cette façon :

$WORKSPACE/symfony test:unit --xml=log/unit.xml
$WORKSPACE/symfony ecr:report --xml=log/coverage.xml



• Pour les résultats des tests unitaires, cochons la case « Publier le rapport des résultats de tests JUnit » puis dans « XML des rapports de test » nous indiquons ou chercher le fichier XML en saisissant : « log/unit.xml »
• Pour le code coverage, cochons la case « Record Emma coverage report » puis dans « Folders or files containing Emma XML reports » nous indiquons où chercher le fichier XML en saisissant : « log/coverage.xml »
• Il faudra ensuite exécuter le job

Affichage du rapport de code coverage

Après lancement du job les résultats du code coverage apparaissent dans la section « Coverage Trend ».

Pour un détail du coverage il faut cliquer sur le graphique.

La couverture du code par les tests unitaire est alors présentée par package ainsi que par classe, méthode, bloc et ligne.

Les blocs sont tous à 0 car c’est une notion seulement utilisée en java. Une méthode ou une classe est couverte si toutes les lignes qui la contiennent sont couvertes. Ainsi certaines classes, ne contenant aucune ligne de code, ayant juste leur déclaration, seront indiquées comme couvertes à 100%.

Bon, mais d’abord, pour les nouveaux, qu’est-ce donc qu’un Mock ? Je ne saurais mieux l’expliquer que Padraic dans son superbe blogpost, mais pour les pressés, on va faire une version courte. Un mock est un remplacement d’objet pour isoler un test. Par exemple, on peut créer des mocks de base de données pour éviter d’instancier tout Propel a chaque test. Voilà, ça c’est pour la théorie.

Toujours pas clair ? Un petit exemple alors. Tout à l’heure j’ai écris des tests (disons pour une classe qui s’appellerait Foobar). C’est une super classe, qui fait son job, pas de problème, mais qui demande en constructeur 2 objets: un Foo et un Bar. Disons que Foo et Bar coûtent un peu cher à instancier. J’ai donc 2 choix: instancier des vrais objets (c’est mal, mais c’est qu’on fait en général), ou utiliser des mocks (c’est bien, mais on le fait pas parcequ’on a la flemme d’écrire les mocks). Qu’à cela ne tienne, avec Mockery, c’est fait en 2 coups de cuiler a pot:
$foo = Mockery::mock('Foo', array('getCreatedAt' => date('Y-m-d H:i:s'));
$bar = Mockery::mock('Bar', array(
'getIsSaved' => true,
'getTitle' => 'recherche titre',
'getDescription' => 'recherche description',
'getIsPublic'=> true ));
$object = new Foobar($foo, bar);
Donc ça c’est la forme un peu « rapide » de création de mock. Pour chaque méthode que je spécifie dans l’array d’options, mockery assigne en valeur de retour la valeur en face. Donc $recherche->getTite() renverra « recherche titre » par exemple. C’est cool non ? Bien sur on peut aller super loin avec Mockery, comme par exemple dire « la méthode tartenpion de l’objet pmsipilotUser doit etre appelé avec en paramètre perlinpinpin et renvoyer un objet MerlinLenchanteur et ne doit être utilisée qu’une fois sinon la terre explose »:
$merlin = new MerlinLenchanteur();
$user = Mockery::mock('pmsipilotUser');
$user->shouldReceive('tartenpion')->with('perlinpinpin')->once()->andReturn($merlin);
(ok je triche encore un peu on ne peut pas vraiment faire exploser la terre) Par contre si on veut vérifier que tout a bien été appelé comme on l’a défini, il ne faut pas oublier de le dire a la fin: Mockery::close(); Un dernier exemple pour vous convaincre de la puissance de Mockery. On rencontre souvent du code qui viole la Loi de Demeter, et qui de fait devient difficile à tester. Point de chichi avec Mockery, car il permet aussi de Mocker une chaine d’appels complète très simplement: $mock = Mockery::mock('demeter'); $mock->shouldReceive('foo->bar->quux->roflpwn->demeter')->andReturn('omgponies'); Magique non ? Pour encore plus de trucs magiques, je vous invite à lire la doc sur la page github de mockery. Voilà j’espère que ça vous aura donné envie d’utiliser un peu plus de Mocks dans vos tests :-)

Au menu :

• le code coupling
• les tests unitaires (en attendant un point complet là dessus le prochain mois)
• les tests d’interface que je propose de réaliser avec Selenium