> Le probleme c'est que les tests unitaires n'attrapent pour ainsi dire jamais les bugs de la vie réelle.
C'est pas vrai du tout. Tout bug attrape par un test unitaire est un bug de la vie reelle, qui aurait pose un probleme a un moment ou a un autre.
Ensuite, il n'y a pas que le kernel dans la vie, il y a plein de logiciels libres qui seraient tres faciles a tester avec des tests unitaires et qui auraient beaucoup a y gagner, mais qui ne le font pas.
> La qualité d'une fonction d'une ou d'un groupe de fonction n'induit pas le bon fonctionnement du logiciel !
C'est faux aussi. Le driver dedie purement a un materiel est plus dur a tester (mais c'est pas du tout impossible) que d'autres parties. Cependant, la qualite d'un groupe de fonction induit grandement la qualite globale d'un logciel. Si on prend l'exemple du kernel:
- la qualite des fs est independante de la qualite des drivers de disque dur. C'est tres facile de tester un FS et c'est d'ailleurs ce qui est fait poru ext3 et reiser
- il y a d'autres parties du noyau facile a tester mais qui ne le sont pas ou du moins pas via des tests unitaires : scheduler, gestion de la memoire.
Il faut voir que des que tu n'es plus a 1 cm du materiel, c'est a dire des que tu sors d'un drivers, tout est testable. Il suffit de faire un pseudo driver dont tu modfifieras le comportement dans tes tests et via lequel tu verifieras que le reste du systeme se comporte correctement.
> Les LL misent généralement sur la période d'incubation
Pour des tres gros projets, c'est peut-etre le cas. Mais la periode d'incubation, ca veut bien dire que tu laisse aux utilisateurs le soin de trouver des bugs. C'est pas une bonne demarche a mon sens, il vaut mieux trouver toi-meme un max de bugs pendant le dev et c'est a ca que servent les tests unitaires.
> Mais c'est la condition pour un débug pertinent:
Je ne suis pas d'accord du tout. Seul une tres petite minorite de bug ne peut etre decouvert que dans des conditions reelles. Une tres grande majorite de bug peut-etre decouvert durant la phase de dev. Le noyau ne fait pas exception. C'est l'argument typique des gens qui ne veulent pas tester: "Je ne peux pas tester ca". Apres, tu leurs presentes des methodes pour qu'ils puissent tester ce qu'ils ne peuvent pas tester mais ils refusent en general des les utiliser parce que ca les obligerait a changer leurs habitudes et a faire evoluer un poil leur architecture.
> Et ça (une longue période d'incubation) c'est très précisément ce que les sociétés developpant des logiciels
> propriétaires ne peuvent quasiment jamais se permettre.
C'est vrai qu'on a tout le temps pour attendre les nouvelles versions stables de debian, ca ne decredibilise pas du tout le projet .
<<
Une autre méthode très généralement utilisé est la relecture et validation systèmatique des modifications du code source proposées. Relecture par non pas par une ou deux personnes (comme avec la méthode XP), mais par un grand nombre de developpeurs très pointus.
>>
Ceci est vrai sur un certain nombre de tres gros projets, mais pas sur beaucoup. Typiquement, pour le noyau, Linus relit les patchs mais l'inverse est rarement vrai.
La relecture s'attache en general a trouver des erreurs de conception. C'est rare qu'on leve des purs bugs comme ca.
Ce que tu dis est complementaire des tests unitaires, mais ne peut en aucun cas s'y substituer.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 4.
C'est pas vrai du tout. Tout bug attrape par un test unitaire est un bug de la vie reelle, qui aurait pose un probleme a un moment ou a un autre.
Ensuite, il n'y a pas que le kernel dans la vie, il y a plein de logiciels libres qui seraient tres faciles a tester avec des tests unitaires et qui auraient beaucoup a y gagner, mais qui ne le font pas.
> La qualité d'une fonction d'une ou d'un groupe de fonction n'induit pas le bon fonctionnement du logiciel !
C'est faux aussi. Le driver dedie purement a un materiel est plus dur a tester (mais c'est pas du tout impossible) que d'autres parties. Cependant, la qualite d'un groupe de fonction induit grandement la qualite globale d'un logciel. Si on prend l'exemple du kernel:
- la qualite des fs est independante de la qualite des drivers de disque dur. C'est tres facile de tester un FS et c'est d'ailleurs ce qui est fait poru ext3 et reiser
- il y a d'autres parties du noyau facile a tester mais qui ne le sont pas ou du moins pas via des tests unitaires : scheduler, gestion de la memoire.
Il faut voir que des que tu n'es plus a 1 cm du materiel, c'est a dire des que tu sors d'un drivers, tout est testable. Il suffit de faire un pseudo driver dont tu modfifieras le comportement dans tes tests et via lequel tu verifieras que le reste du systeme se comporte correctement.
> Les LL misent généralement sur la période d'incubation
Pour des tres gros projets, c'est peut-etre le cas. Mais la periode d'incubation, ca veut bien dire que tu laisse aux utilisateurs le soin de trouver des bugs. C'est pas une bonne demarche a mon sens, il vaut mieux trouver toi-meme un max de bugs pendant le dev et c'est a ca que servent les tests unitaires.
> Mais c'est la condition pour un débug pertinent:
Je ne suis pas d'accord du tout. Seul une tres petite minorite de bug ne peut etre decouvert que dans des conditions reelles. Une tres grande majorite de bug peut-etre decouvert durant la phase de dev. Le noyau ne fait pas exception. C'est l'argument typique des gens qui ne veulent pas tester: "Je ne peux pas tester ca". Apres, tu leurs presentes des methodes pour qu'ils puissent tester ce qu'ils ne peuvent pas tester mais ils refusent en general des les utiliser parce que ca les obligerait a changer leurs habitudes et a faire evoluer un poil leur architecture.
> Et ça (une longue période d'incubation) c'est très précisément ce que les sociétés developpant des logiciels
> propriétaires ne peuvent quasiment jamais se permettre.
C'est vrai qu'on a tout le temps pour attendre les nouvelles versions stables de debian, ca ne decredibilise pas du tout le projet .
<<
Une autre méthode très généralement utilisé est la relecture et validation systèmatique des modifications du code source proposées. Relecture par non pas par une ou deux personnes (comme avec la méthode XP), mais par un grand nombre de developpeurs très pointus.
>>
Ceci est vrai sur un certain nombre de tres gros projets, mais pas sur beaucoup. Typiquement, pour le noyau, Linus relit les patchs mais l'inverse est rarement vrai.
La relecture s'attache en general a trouver des erreurs de conception. C'est rare qu'on leve des purs bugs comme ca.
Ce que tu dis est complementaire des tests unitaires, mais ne peut en aucun cas s'y substituer.