Honnetement, au lieu de sauter sur le troll proprio/libre, vous devriez reflechir a la facon d'augmenter la qualite des logiciels libres.
Ce que je partage avec l'auteur de cette news comme point de vue, c'est que les tests unitaires ne sont pas assez utilise en logiciel libre. C'est un tort car ca permet de faire evoluer tres rapidement l'architecture d'un logiciel tout en conservant sa qualite. Si je prends une appli comme grisbi, il y a eu des versions completement inutilisables tellement elles etaient buggees. Pourtant, c'est pas dur d'ecrire des tests unitaires pour les fonctionnalites qui posaient probleme.
Depuis que je suis devenu un integriste du test unitaire, je constate que j'ai beaucoup moins de bugs sur mes projets et qu'ils sont beaucoup plus faciles a faire evoluer. Constation corroboree par d'autres convertis du test unitaire.
Alors le test unitaire, mangez-en. On peut en faire en C (cunit), en C++ (cppunit), en pyton (unittest), en java (junit, easymock), et C#, en ruby et en tout ce que vous voulez. L'important est d'avoir une suite de test automatisee.
Le contre-argument classique est "mais on ne peut pas tester cette partie-la". Avec un peu d'astuce, on peut tout tester mais il faut s'en donner les moyens. Par exemple, j'ai peu tester un protocole de communication radio ou il fallait simuler des conditions radio anormales. Je travail aussi sur du code embarque ou il faut tester le comportement d'un programme compile avec de l'overlay (pas de notion de fonctionr re-entrante, les variables locales ne sont pas sur la piles mais a des emplacements fixes). Ca aussi, on a put tester sans probleme a condition de reflechir a la facon d'aborder le probleme.
Ce qui est genial, c'est qu'une fois que les briques de bases ont beaucoup de tests unitaires, c'est tres tres facile de faire des tests fonctionnels de tres haut niveau, en assemblant des briques de tests unitaires.
Par exemple, une fois que j'ai eu mon protocole de communication debugge, j'ai pu teste l'ensemble de mon programme avec introdution de conditions radio anormales et autres petits problemes. J"etais doublement confiant dans sa qualite.
[^] # Re: Ah oui mais...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 10.
Ce que je partage avec l'auteur de cette news comme point de vue, c'est que les tests unitaires ne sont pas assez utilise en logiciel libre. C'est un tort car ca permet de faire evoluer tres rapidement l'architecture d'un logiciel tout en conservant sa qualite. Si je prends une appli comme grisbi, il y a eu des versions completement inutilisables tellement elles etaient buggees. Pourtant, c'est pas dur d'ecrire des tests unitaires pour les fonctionnalites qui posaient probleme.
Depuis que je suis devenu un integriste du test unitaire, je constate que j'ai beaucoup moins de bugs sur mes projets et qu'ils sont beaucoup plus faciles a faire evoluer. Constation corroboree par d'autres convertis du test unitaire.
Alors le test unitaire, mangez-en. On peut en faire en C (cunit), en C++ (cppunit), en pyton (unittest), en java (junit, easymock), et C#, en ruby et en tout ce que vous voulez. L'important est d'avoir une suite de test automatisee.
Le contre-argument classique est "mais on ne peut pas tester cette partie-la". Avec un peu d'astuce, on peut tout tester mais il faut s'en donner les moyens. Par exemple, j'ai peu tester un protocole de communication radio ou il fallait simuler des conditions radio anormales. Je travail aussi sur du code embarque ou il faut tester le comportement d'un programme compile avec de l'overlay (pas de notion de fonctionr re-entrante, les variables locales ne sont pas sur la piles mais a des emplacements fixes). Ca aussi, on a put tester sans probleme a condition de reflechir a la facon d'aborder le probleme.
Ce qui est genial, c'est qu'une fois que les briques de bases ont beaucoup de tests unitaires, c'est tres tres facile de faire des tests fonctionnels de tres haut niveau, en assemblant des briques de tests unitaires.
Par exemple, une fois que j'ai eu mon protocole de communication debugge, j'ai pu teste l'ensemble de mon programme avec introdution de conditions radio anormales et autres petits problemes. J"etais doublement confiant dans sa qualite.