Dieu merci, les tests de régression. J'étais là, au début de la semaine, à me sentir vraiment bien par rapport à un nouveau code que j'avais écrit et (je pensais) débogué. Je suis en train d'améliorer les fonctions POSIX d'OpenVOS qui convertissent les valeurs de temps binaires en structure de temps décomposée ("struct tm" pour vous, experts du C). En 1998, lorsque j'ai initialement modifié ces routines pour travailler dans l'environnement POSIX, j'ai pris un raccourci et j'ai appelé les sous-routines du noyau VOS sous-jacentes. Cette approche était rapide et simple, mais elle signifiait que nos exécutions POSIX ne pouvaient pas gérer les dates entre 1970 et 1980, car VOS ne gère pas ces dates. Dernièrement, j'ai porté plusieurs nouveaux paquets open-source majeurs vers OpenVOS 17.0. J'ai découvert que nous avions échoué à un certain nombre de tests parce que nous ne pouvions pas gérer cette plage de dates. J'ai donc entrepris de modifier le code pour gérer toutes les dates des époques VOS et UNIX (1970 à 2048). Je savais que cette tâche serait sujette à des erreurs et j'étais déterminé à trouver un moyen de supprimer tous les bogues du code. L'un des avantages de travailler avec des dates est que l'ensemble est fini. De plus, comme les ordinateurs modernes sont assez rapides, il n'est pas si difficile de les faire fonctionner en utilisant toutes les combinaisons possibles et de voir ce qui se passe. Je voulais m'assurer de tester la zone du code qui traite des années 1970 et 1971, pour des raisons que je n'aborderai pas ici. J'ai donc écrit un test qui convertissait 2 fois par jour, à partir du 1er janvier 1970 et jusqu'à aujourd'hui. Il n'a utilisé qu'une fraction de seconde de temps CPU. Bien sûr, j'ai trouvé une erreur de fencepost dans mon code. J'ai corrigé l'erreur et le test a réussi. Je me sentais plutôt bien dans ce processus, et mes auditeurs ont approuvé les changements, et je pensais avoir terminé. Ensuite, un de mes collègues a fait passer la suite de tests de régression sur mes modifications. Nous faisons cela après chaque modification des compilateurs et de leurs exécutions, juste pour être sûrs de ne rien casser accidentellement. Malheureusement pour moi, plusieurs des tests de régression ont échoué. Lorsque j'ai découvert pourquoi mes tests n'avaient pas réussi, malgré l'apparente minutie du test, j'ai découvert que les problèmes ne se sont pas posés avant 2038. Alors que j'avais ajouté la décennie de 1970 à 1980 aux routines temporelles, j'avais coupé la décennie de 2038 à 2048. Bien sûr, lorsque je suis retourné faire des tests tous les jours dans la gamme, j'ai prouvé que mon test aurait détecté le problème, si seulement je le lui avais demandé.
Quelle est la leçon à en tirer ? Je suppose que la plus évidente est que si vous pouvez tester toutes les combinaisons, alors assurez-vous que vous les testez réellement toutes. La leçon la plus importante est peut-être de prendre le temps de construire une suite de tests de régression. Le temps et les efforts en valent la peine. Ils peuvent réduire les coûts et raccourcir le temps nécessaire pour trouver et résoudre les problèmes au fur et à mesure que vous améliorez votre code. Il n'est pas nécessaire d'éviter de nombreux problèmes signalés par les clients pour justifier le coût de la création d'une suite de tests de régression. J'estime que le coût de la correction d'un problème logiciel augmente d'un ordre de grandeur à chaque phase supplémentaire du processus. Comme il y a au moins 4 phases dans tout processus (conception, codage, test, déploiement), les choses deviennent rapidement coûteuses.
Entreprise