L'argument de dire que quand on utilise de vieux algo / structure de données donne moins de bug ne prouve rien ! D'autant plus que les contraintes de l'époque ne sont plus les mêmes aujourd'hui ...
Mais je n'entend rien prouver du tout. J'expose un fait, et j'avance une explication. Si tu en as une meilleure, je suis preneur.
Les problèmes d'allocation mémoire, ce n'est qu'une infime partie des bugs qui ne sont pas détectés par les outils d'analyse de code généralement ...
Possible, mais les bugs que j'ai exposé dans mon précédent commentaire constituent la quasi-majorité de ceux que je rencontre, et le fait est qu'ils sont relatifs de manière générale à la gestion de la mémoire dynamique.
Il y a tout un tas de problèmes que tu ne peux pas détecter même en diversifiant les contextes de combinaison d'appel de tes fonctions, avec en vrac :
les effets de bord de ré-utilisation des ressources déjà utilisées
les effets de bord dû aux accès concurrentiels
les effets de bord dû au fait que tu ne contrôle pas l’environnement d’exécution ou les entrés de tes fonctions
etc.
Problématiques que j'ai prises en compte lors du développement de mes bibliothèques. Et les problèmes qui m'auraient échappés, vu depuis combien de temps j'utilise ces bibliothèques, il y a belle lurette que les bugs afférents se sont révélés et que je l'ai ai corrigés (là encore, c'est juste une hypothèse, mais je n'en vois pas d'autre ; et je le rappelle : l'élément-clef de ma méthode de développement, c'est la factorisation).
Bref, tout ça pour dire qu'à mon humble avis, me concernant, c'est très difficile et peu rassurant de ne pas avoir à minima du test unitaire à l'intérieur des API qu'on écrit soit même.
Je ne vois pas où est la difficulté, mais je suis parfaitement d'accord ; savoir que du code a passé une batterie de tests, unitaires ou autres, est très rassurant pour celui qui l'a développé, et je ne fais pas exception. Peut-être suis-je le développeur le plus chanceux de l'univers, mais pourquoi diable irai-je écrire des tests qui, en l'état actuel du code que je développe, ne me servirait qu'à me faire perdre du temps ?
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: Faire des tests, c'est bien, mais...
Posté par Claude SIMON (site web personnel) . En réponse au journal Faites des tests !. Évalué à 1.
Mais je n'entend rien prouver du tout. J'expose un fait, et j'avance une explication. Si tu en as une meilleure, je suis preneur.
Possible, mais les bugs que j'ai exposé dans mon précédent commentaire constituent la quasi-majorité de ceux que je rencontre, et le fait est qu'ils sont relatifs de manière générale à la gestion de la mémoire dynamique.
Problématiques que j'ai prises en compte lors du développement de mes bibliothèques. Et les problèmes qui m'auraient échappés, vu depuis combien de temps j'utilise ces bibliothèques, il y a belle lurette que les bugs afférents se sont révélés et que je l'ai ai corrigés (là encore, c'est juste une hypothèse, mais je n'en vois pas d'autre ; et je le rappelle : l'élément-clef de ma méthode de développement, c'est la factorisation).
Je ne vois pas où est la difficulté, mais je suis parfaitement d'accord ; savoir que du code a passé une batterie de tests, unitaires ou autres, est très rassurant pour celui qui l'a développé, et je ne fais pas exception. Peut-être suis-je le développeur le plus chanceux de l'univers, mais pourquoi diable irai-je écrire des tests qui, en l'état actuel du code que je développe, ne me servirait qu'à me faire perdre du temps ?
Zelbinium: pour la génération qui crée, pas celle qui scrolle...