Le bug de l’an 2000 aura lieu en 2038 !

“Dis Papy, c'était quoi le bug de l'an 2000?”

D'abord nous ne sommes pas vieux et arrêtez de m’appeler Papy  !!! 

Pour les jeunots qui ne connaissent pas , le bug de l'an 2000 c'était ça : INA France 2 Bug l'an 2000

En résumé, à l'époque, il se disait que les ordinateurs seraient obsolètes, dû à un problème de conception sur le format de dates. Certains programmes avaient été implémentés avec le format des années dans les dates avec le format YY.

Pour le bug de l'an 2000, au final rien de spécial ne s'est passé, aucun avion ne s'est crashé au final et nous ne sommes pas retournés dans le passé. Bon, cela est du passé, intéressons-nous maintenant à un problème futur.

Quel est donc le problème avec 2038 ?

Le problème “2038” s'apparente au Bug de l'an 2000. Il s'agit également d'un bug de conception concernant les logiciels utilisant la représentation POSIX. Il impactera, entre autres, des systèmes de gestion de fichiers qui utilisent un format de 32 bits tels que :

• FAT32
• ext4 (des mises à jours sont mise en place par la communauté Linux)
• ext3 (comme pour ext4)

Mais d'où pourrait bien venir un tel bug ? Encore une fois, l'erreur est humaine . En fouillant un peu, un commentaire a été découvert avec le message fictif suivant : 

A première vue, le bug était connu dès l'étape de conception par le développeur. Mais qu'est-ce que cela provoquera sur les systèmes 32 bits ? Voici un exemple de code sur les conséquences de ce code 

Là, comme par magie, nous retournons dans le passé. Bon, vu ainsi cela fait bien rire, mais imaginez les systèmes qui n'ont pas été “mirgés” depuis belle lurette...

Là cela fera moins rire .

Heureusement, ce bug est en cours de résolution sur la plupart des systèmes .

Ok, c’est bien beau tout ça mais comment aurait on pu détecter le code plutôt ?

Maintenant tout le monde visualise le bug et comprend les impacts qu'il engendrera.

Ce que nous souhaitons ici démontrer, c'est qu'il est facile de faire en sorte que le code fonctionne à un certain moment, mais qu’il est nécessaire lors de la conception de logiciel de prendre en compte les éléments futurs et de voir plus loin que le moment T.

À un moment ou à un autre, il faudra passer à la caisse et ça peut faire mal 

D'où le problème de conception. Le développeur a peut-être été pressé de finir au plus vite, soit sous la pression, soit en se disant qu'il aura le temps de repasser, ou les deux qui sait.

Cependant, le temps passe, il y a d'autres priorités et le temporaire devient définitif , et nous y voilà : un beau bug à retardement ! 

Les tests effectués à l'époque ont dû démontrer un fonctionnement sommaire et les ingénieurs-développeurs ne se sont pas attardés à des tests plus poussés.

La programmation pilotée par le comportement ou BDD pour les intimes 

Nous pouvons le dire au début de l'informatique, il n'existait pas de Framework ou de méthodologie pour assurer la stabilité d'un logiciel dans le temps (en supposant que le logiciel connaît des évolutions et est maintenu).

Seuls les tests de non-régressions étaient effectués, soit par des logiciels de type Micro Focus Quality Center (ancien Hp Quality Center), Selenium IDE, soit tout bonnement par des équipes QA dédiées.

Les problématiques les plus souvent rencontrées sont le maintien du cahier de tests ainsi que le transfert de connaissance entre les QA et les développeurs.

Pour résoudre ce problème, est apparu dans les années 2000, le Framework BDD pour Behavior Driven Design. Le BDD est une extension au Framework des Tests unitaires TDD, pour laquelle il n'est pas forcément question de tester localement une fonction, lisible uniquement par les développeurs seuls.

Le BDD permet en effet de créer une synergie entre les développeurs, QA, commerciaux et toute autre personne intervenant sur le projet via un langage commun qui sera utilisé pour expliquer la fonctionnalité d'une feature, voire de l'application en elle-même.

Il existe de nombreux Frameworks de BDD utilisables sur une large panoplie de langages de programmation:

• Java
  • JBehave
  • Cucumber-JVM
• .Net
  • Specflow
  • xBehave
• Javascript
  • Jasmine
  • Mocha
• Python
  • Behave
  • Lettuce
• X-Langage
  • Cucumber

Avec cette méthodologie, et ces outils, nous sommes sûrs, à moins d'avoir oublié des cas, d'implémenter ce qui est demandé. Cependant, comment faire pour rendre le code encore plus robuste.

Les Tests de Propriétés

L'avantage des tests de propriétés est, en plus des tests unitaires et des tests créés pour le bdd, de permettre la création d'un jeu de données aléatoires pour pouvoir tester la robustesse d'un programme.

Comme dans l’exemple ci-dessous un peu simpliste certe qui permet déterminer si la générations de différentes dates pour afficher le nom. 

Le mot de la Fin

En conclusion, nous avons vu qu'une application non testée peut présenter des problèmes des années plus tard. Et qu'il est nécessaire :

• que tous les intervenants d'un produit s'impliquent dans la conception et les tests pour répondre au mieux aux demandes des clients. 
• de faire des tests en profondeur en plus des tests unitaires classiques que ce soit du BDD ou des tests de propriétés.

Ces deux frameworks feront partie d'articles un peu plus détaillés dans le futur ;-).

++

Idhir Madjour - Practice Leader CAPFI Technology