Soyez brut et fruste... pour commencer

17/12/2009 Développement:// Soyez brut et fruste... pour commencer
Je souhaite, pour chaque projet sur lequel je travaille, pouvoir déterminer la couverture du code assurée par les tests unitaires. En gros, repérer les portions du code qui ne sont pas exécutées pendant les tests, et donc dont les erreurs ne pourront pas être détectées automatiquement.

Quelques écueils dans mon projet :
- entre Windows et Linux la ligne de commande change un peu, les chemins notamment
- d'un poste à l'autre je ne souhaite pas forcément stocker les fichiers au même endroit
- Entre Linux et Windows je n'ai pas de langage commun nativement, donc soit je scripte en PHP, soit j'installe bash pour Windows, soit...
Bref, toutes choses fort simples mais qui demandent de mettre en place une petite abstraction, de tester sur les différentes machines, de résoudre des cas particuliers sur chacune peut-être... En sachant qu'il faut déployer les nouvelles versions sur chaque machine, ce qui peut être fréquent en phase de développement.

La solution est d'explorer en évitant un maximum de perte de temps. J'ai donc simplement écrit un script pour chaque plateforme, pour un seul projet, et j'ai tout stocké via le dossier SVN de ce projet.

Soit donc un batch pour Windows
rmdir /s /q C:\wamp2\www\couverture_tests\monprojet
C:\wamp2\www\utilitaires\include\pear-phpunit.bat --coverage-html C:\wamp2\www\couverture_tests\monprojet TU C:\wamp2\www\perso\monprojet\testsUnitaires\index.php

Un script Bash pour Linux
rm -rf ~/www/couverture_tests/monprojet
~/www/outilsweb/utilitaires/include/pear-phpunit --coverage-html ~/www/couverture_tests/monprojet TU ~/www/monprojet/testsUnitaires/index.php

et ainsi de suite.

Ainsi je teste immédiatement, repérant notamment une étrange différence dans le comptage des classes et lignes de codes qu'il me faut résoudre. Imaginez que j'ai déployé sur toutes mes machines, postes et serveurs de développements, plus les postes de mes collègues, avant de me rendre compte de ce "détail"?
Avant de peaufiner, j'ai besoin de faire mûrir ma compréhension du projet, et de faire mûrir le projet lui même, de le confronter à petite échelle, très rapidement, avec le monde réel.

J'ai déjà appliqué la même technique dans d'autres domaines, elle est très souvent pertinente à mon goût.

Rubriques des billets

Commentaires(s)

2009-12-17 23:17:44 - senjy
Désolé, mais est ce possible d'être clair?

Le sujet est intéressant, il mérite d'être plus didactique.
2009-12-18 08:11:37 - Cédric
Oui, c'est même un sujet important à mon sens, mais si vous me dites ce qui manque de clarté il sera plus facile pour moi de re-développer ces parties. Les billets d'un blog peuvent aussi être affinés grâce aux remarques des visiteurs, tout comme le programme dont je parle va s'affiner au fur et à mesure de son utilisation.
2009-12-29 17:46:38 - Didier Bretin
Effectivement ce n'est pas très clair ;). Tu sembles vouloir parler d'un projet dans l'absolu, puis tu donnes un exemple et tu conclues par une phrase "mystique" :). Là, moi aussi, je ne comprends pas bien où tu veux en venir ...
2009-12-30 18:43:30 - Cédric
En fait l'idée pragmatique est de répondre immédiatement et le plus simplement possible au besoin, afin de gagner de l'expérience en utilisant le bricolage mis en place, et d'avancer vers les besoins suivants.
Il n'y a rien de mystique, juste une métaphore : faire mûrir notre compréhension d'un problème et de sa solution informatique prend du temps et des conditions spéciales, tout comme faire murir un fruit demande du temps, du soleil, un sol nourrissant, de l'eau, ...

Ecrire votre commentaire

17/12/2009 - Systeme