Les tests unitaires sont un thème récurrent pour moi ces dernières semaines; entre les discutions sur Stackoverflow et d’autres forums et les tests que j’écris pour deux projets en cours, je me suis posé quelques questions quant au coût réel de ces tests unitaire.

C’est surtout un article de Thomas Brandt (en allemand: « TDD in der (meiner) Praxis – Wunsch und Wirklichkeit ») qui m’a fait réfléchir sérieusement. Dans son article Brandt décrit assez bien le gouffre bel et bien présent entre la théorie et la pratique du Test Driven Developpement. De but en blanc, il adhère plutôt aux principes du TDD;

Je dois tout d’abord dire que le Test Driven Development, surtout le principe „test first“, est une manière plutôt « sexy » de développer. Elle permet très certainement d’améliorer l’architecture du logiciel et nous évite de faire certaines (petites) erreurs.
— Traduction relativement libre des propos de T. Brandt

Il considère donc TDD comme un outil performant – du moins d’un point de vue purement académique. Mais la suite immédiate constitue un doute;

La question est simplement: à quel prix?

Comme dit, hormis T. Brandt et moi, bien d’autres personnes semblent se poser la question, et la question la plus fréquente est la suivante: est-ce que l’utilisation de tests unitaires produit-elle réellement des logiciels de meilleure qualité, et est-ce que les efforts à investir sont-ils réalistes?

Condensée, la question se résume à un simple:

Ça me coûte combien les tests unitaires?

Souvent la question implique, que celui qui la pose pense que les tests unitaires sont bien trop chers pour les appliquer de manière conséquente. Je me souviens d’une discussion que j’ai eue à propos de l’intérêt d’une couverture de test totale en dehors de l’idéal théorique. Rapporté aux efforts à fournir j’ai répondu que « non » à l’époque.

Au jour d’aujourd’hui je trouve que toutes ces questions sont simplement mal posées, car ce n’est pas connaitre le coût des tests unitaires qui est important, mais:

Combien me coûte l’omission des tests unitaires?

Et voici ma réponse, illustrée à l’aide d’un exemple concret;

L’un de mes projets actuels comprend un grand nombre de composantes distribuées. J’ai découvert une erreur dans le projet, ce qui m’a forcé à refactoriser deux classes. Le tout m’a pris environ 1 heure. Lancer les tests unitaires? Environ 30 secondes. 30 secondes qui m’ont fait découvrir que certains comportements n’étaient plus comme prévus initialement. Il m’a fallu environ 20minutes pour les corrections. L’écriture des tests m’avaient coûté environ 45min.
Le bilan est donc environ de deux heures.

Sans les tests unitaires, je n’aurais surement pas remarqué une partie des erreurs immédiatement. J’aurais donc eu 1 heure de refactorisation, plus un temps plus ou moins indéterminable, certainement réparti sur plusieurs jours, pour corriger les problèmes passés inaperçus lors du changement. La probabilité que ce temps dépasse largement une heure est relativement grande (débugger « à la main », recréer les conditions dans des applis multi-threadées etc…).

Pour ma part, je conclus que pouvoir calculer avec un temps défini (en ayant des tests couvrant une partie réaliste du logiciel – pas 100%) est plus intéressant que la navigation à l’aveuglette tant pratiquée.

Faites des tests!

MariaDB un fork de MySQL

Un message très heureux m’est parvenu de MariaDB, le fork très prometteur de MySQL. Avec un commit très récent dans leur repository, MariaDB se permet d’assouplir un peux le modèle relationnel classique. Avec l’introduction des colonnes dynamiques (traduction libre de « Dynamique Column ») la prochaine version (5.3) de MariaDB contiendra donc apparemment un zeste de noSQL!

Un but principal lors du développement était de rendre ces colonnes utilisables via une syntaxe SQL classique. De façon interne les colonnes dynamiques sont sauvegardées en tant que BLOB (Binary Large Object).

Pour illustrer un peux le fonctionnement de ce nouveau type, un petit exemple:

1
2
3
4

INSERT INTO exemple (nom, classe, prix, attributs) VALUES
("HTC Desire Z", "telephone", 420, COLUMN_CREATE(1.5, "Gris")),
("Nokia E7", "telephone", 509, COLUMN_CREATE(32, "noir", 2, "Clavier")),
("Lenovo Thinkpad E420", "ordinateur", 1019, COLUMN_CREATE(1, "noir", 3, "Win7 Pro", "500Go"));

Comme vous pouvez donc le voir, le tout ressemble à une requête tout à fait classique, au détail de la colonne « attributs » près. Dans l’exemple chaque entrée possède donc des données classiques, plus un champ « attributs » qui contiens un nombre variable de données (N.B.: contrairement aux champs classiques, une entrée de tableau dynamique ne possède qu’un numéro d’adressage, mais apparemment les développeurs comptent encore changer ça).

Pour créer une entrée pour la colonne on utilise donc COLUMN_CREATE(), pour mettre à jours ou effacer une entrée il faut utiliser la fonction COLUMN_ADD() dans un appel UPDATE normal:

1
2

UPDATE exemple SET attributs=COLUMN_ADD(attributs, 1, "jaune")
  WHERE COLUMN_GET(attributs, 1 AS CHAR(10)) = "noir";

L’exemple illustre aussi assez bien l’utilisation de COLUMN_GET() qui permet d’accéder à un attribut de la colonne. Il existe aussi COLUMN_LIST() qui retourne la liste des colonnes dynamiques présentes.

Si jamais vous souhaitez déjà essayer cette nouvelle fonctionnalité, jettez-vous sur votre compilateur et le repository de MariaDB; les binaires ne seront disponibles qu’avec la version 5.3 de MariaDB.

Tests logiciels - une science pour sois

Je viens tout juste de lire l’étude Software Integrity Risk Report qui à été réalisée à la demande de Coverity. Dans les grandes lignes l’étude résume assez bien une impression que j’ai depuis bien longtemps; le développeur moyen est bien moins soucieux de la qualité d’un logiciel tiers qu’il intègre dans un projet que de la qualité de son propre code.

Concernant les chiffres, l’étude dit que 90% des (330) développeurs utilisent des sources tierces (qu’elles soient Libres de droit ou propriétaires) dans leurs logiciels. Par contre seul environs 40% de ces développeurs disent procéder à des tests automatisés sur ces sources (contre plus de 75% pour les sources « maison »). Il en est de même (à quelques pourcents près) pour les tests manuels et d’intégrité (stress-testing/functional-testing).

Une certaine unanimité règne quant aux retards pris à cause d’une qualité insuffisante du code tiers; plus de 140 développeurs ont répondu qu’une grande partie des retards de lancements ou des rappels étaient dû à des soucis avec des sources tierces.

Le mot final: TESTEZ! TESTEZ! TESTEZ!

Cela faisait longtemps qu’on savais tous que le Javascript n’était pas que là pour valider des formulaires (X)HTML et à faire quelques effet sur les sites web. Mais aujourd’hui M. Fabrice Bellard a encore frappé avec une démonstration d’envergure!

Ce génie a bel et bien réalisé un émulateur x86 en pure javascript! Je vous épargne les détails techniques ici (ils sont lisibles sur le site de Fabrice Bellard). En gros, JSLinux est un émulateur de 486, sans FPU et MMX, mais avec une unité de gestion mémoire (MMU) complète!

Une particularité technique (qui à rendu possible cet exploit) est l’utilisation extensive de tableaux typés (spécification par là) qui sont disponibles depuis peu dans les navigateurs récents (Chrome 11 et Firefox4 actuellement, Opera étant entrain de rattraper le retard si mes informations sont bonnes).

Concernant la « distro » linux installée dans la démo, elle est pas mal complête; kernel 2.6.20, BusyBox, vi, qEmacs et un compilateur C (TinyCC, que j’ai eu la joie d’essayer pour la première fois =)

Sur ce, je vous laisse découvrir vous-même cette merveille: JSLinux (la page met quelques secondes à charger)

Et moi voilà de retour avec une petite bricole Linux: installer Mono 2.10 sur CentOS (5.6 pour le coup).

Quelques heures de recherche sur le net m’ont toujours amenées vers le même résultat; compiler depuis les sources… et avec la belle liste des dépendances, rien de très amusant… la solution: se casser un petit-peu la tête!

Lire la suite