mercredi 3 juin 2009

Ecrire du code objet en PHP testable

Au vu de ce que je lis sur Internet actuellement à propos de PHP, les tests unitaires ont le vent en poupe.

Cependant, l'écriture des tests, et plus particulièrement d'un code testable, n'est pas forcément une chose évidente pour un développeur.

En effet, au fil du temps, ce dernier peut avoir pris un certain nombre d'habitudes qui font que le code qu'il conçoit n'est pas testable facilement.

Cependant, il lui suffit de prendre conscience de la condition qui permet de tester du code pour résoudre le problème.

Lire la suite

vendredi 15 mai 2009

unserialize() et autoload

Il y a a quelques jours, en travaillant sur l'un de mes projets personnels, j'ai eu droit, à ma grande surprise, à la magnifique erreur PHP suivante :

Fatal error: uneClasse::__destruct(): The script tried to execute a method or access a property of an incomplete object.
Please ensure that the class definition "uneAutreClasse" of the object you are trying to operate on was loaded _before_
unserialize() gets called or provide a __autoload() function to load the class definition
in /le/fichier/qui/ne/fonctionne/pas.php on line 33

En gros, j'essayais de deserializer un objet d'une classe dont mon script ne connaissait pas la structure car l'autoload que j'avais mis en place ne parvenait pas à localiser le fichier contenant la classe en question.

Seul problème, le code concerné, éxécuté dans le cadre d'un test unitaire, ne faisait aucun appel à unserialize().

Chose encore plus étrange, en modifiant mon test de façon à ne pas générer d'exception, l'erreur disparaissait.

Lire la suite

jeudi 7 mai 2009

Tester unitairement du code avec des dépendances externes

Bien souvent, le code PHP que nous devons écrire dépend de composants externes, comme par exemple :

  • Des bases de données.
  • Des connexions réseaux.
  • Des fichiers locaux ou distants.
  • Des segments de mémoire partagés.
  • Du code d'un autre développeur.

Ces composants externes ont la particularité de ne pas forcément être disponibles à tout moment et de manière fiable, et cela pour tout un tas de raisons, tel que :

  • La base de données à utiliser est une base de données propriétaire qui demande une licence et/ou est une vrai usine à gaz qui demande des compétence en administration de bases de données dont vous ne disposez pas.
  • Votre machine de développement est une machine itinérante qui ne dispose pas d'une connexion permanente à un réseau, et vous ne pouvez donc pas avoir les connexions nécéssaires, ou bien votre connexion est trop lente et entraîne un ralentissement important lors de l'éxécution des tests.
  • Le format des fichiers n'est pas encore défini, ou bien vous n'en disposez pas car ils sont estampillés secret défense (qui a pensé à la comptabilité de l'entreprise ou figure le salaire du patron ?).
  • Votre système d'exploitation ne supporte pas les segments de mémoire partagés, ou bien une des technologies que vous devez intégrer dans votre code.
  • Le développeur chargé du code dont dépend votre travail a un retard de six mois, ou bien est en longue maladie, etc.

Or, les tests unitaires doivent pouvoir être éxécutés automatiquement, à tout moment, et rapidement.

Ces dépendances externes posent donc un problème vis à vis des tests, puisqu'ils ne sont pas fiables.

Lire la suite

mardi 14 avril 2009

Mesurer la testabilité à l'aide d'une métrique

Je me permet de réagir au billet d'Olivier Hoareau à propos de l'injectabilité/mockabilité d'un code source comme indicateur de la testabilité dudit code.

Olivier préconise d'utiliser la formule suivante pour mesurer la testabilité d'un code, arguant du fait que plus un code est modulaire et découplé, plus il est testable :

i = (nb getters + nb setters) / (2 * nb propriétés) avec 0 <= i <= 1

Si je suis d'accord avec le fait qu'un code découplé et injectable est plus facilement et efficacement testable, je trouve que sa formule insuffisante et trop restrictive, car elle ne prend pas en compte l'encapsulation.

Lire la suite

jeudi 11 décembre 2008

Mock ?

Lors du dernier forum PHP, j'ai eu une intéressante conversation avec Laurent, le créateur de Jelix, à propos des mocks.

En effet, il sait que nous utilisons de manière intensive les tests unitaires chez No Parking pour nos développements.

Il souhaitait donc savoir si nous utilisions cette chose, et dans l'affirmative, ce qu'elle nous permettait de réaliser, car il avait des difficultés à en saisir l'utilité.

Suite à cette conversation, je me suis dis qu'il n'était peut être pas inutile d'en partager le contenu, les mocks étant de mon point de vue assez peu connus et encore moins utilisés.

Lire la suite

page 2 de 2 -