Tout d'abord remercions l'auteur de cette news car il soulève un problème intéressant. Je suis effaré par la stupidité de pas mal de commentaires faits par des gens qui :
- confondent tests unitaires et leurs pratiques de bricoleurs (#ifndef, tester les valeurs en entrée de fonction, tester l'application dans leur coin, ...)
- n'ont jamais essayé la pratique des tests unitaires avec un framework adéquat
- font confiance dans la grandeur de leur esprit pour ne pas faire de fautes
- fusillent l'auteur de la news en partant dans un troll hors-sujet tout ça parce qu'il ose mettre en doute certains assertions de la grande communauté du libre.
Pratiquer les tests unitaires, c'est pourtant simple et on se rend très vite compte des avantages que cela apporte. En premier lieu on développe des composants que l'on teste de suite. Assembler des composants blindés aux tests donne un assemblage de meilleure qualité. En second lieu, cela a un impact indéniable sur la modélisation. Un composant difficile à tester est souvent un composant mal modélisé. On va donc chercher à le découpler au maximum de ces dépendances. Au final cela force à faire les choses proprement et l'impact sur le logiciel final est évident. Enfin une autre bonne pratique est que quand je découvre un bug, je ne me jette pas dessus pour faire un correctif. Je cherche d'abord à le reproduire/isoler dans un test unitaire. Une fois cette étape faite, je peux apporter la correction. J'évite ainsi à l'avenir les régressions. Cela peut sembler contraignant voir inutile pour certains, mais cela paie systématiquement quand un projet prend de la taille.
Il serait également stupide de croire que les tests unitaires sont inutiles pour de petits projets. Le temps passé sur les tests lors de la conception (les tests ça ne s'écrit pas après sinon c'est inutile) est largement compensé au final car on converge plus vite vers un logiciel qui marche. Il faut essayer pour s'en rendre compte, ça ne semble pas évident de prime abord ...
Pas mal de techniques récentes intègrent cette notion. Je pense en particulier à l'IoC (Inversion of Control) qui permet l'obtention d'assemblages modulaires de composants découplés. Du coup ces composants sont très simples à tester. Le logiciel est ainsi meilleur.
Enfin il faudrait arrêter de prendre les systèmes de rapport de bugs comme des outils ultimes. Les utilisateurs sont là pour utiliser un logiciel, pas pour chercher dans le code la raison d'un bug. Si certains le font c'est tant mieux, mais la majorité ne le fera pas. Quand on critique MS qui prend ses utilisateurs pour des testeurs tout le monde trouve ça normal, mais quand c'est pour un logiciel libre, tout le monde dit : "envoie un rapport de bug et un patch si possible"...
# Stop !
Posté par Anonyme . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 10.
- confondent tests unitaires et leurs pratiques de bricoleurs (#ifndef, tester les valeurs en entrée de fonction, tester l'application dans leur coin, ...)
- n'ont jamais essayé la pratique des tests unitaires avec un framework adéquat
- font confiance dans la grandeur de leur esprit pour ne pas faire de fautes
- fusillent l'auteur de la news en partant dans un troll hors-sujet tout ça parce qu'il ose mettre en doute certains assertions de la grande communauté du libre.
Pratiquer les tests unitaires, c'est pourtant simple et on se rend très vite compte des avantages que cela apporte. En premier lieu on développe des composants que l'on teste de suite. Assembler des composants blindés aux tests donne un assemblage de meilleure qualité. En second lieu, cela a un impact indéniable sur la modélisation. Un composant difficile à tester est souvent un composant mal modélisé. On va donc chercher à le découpler au maximum de ces dépendances. Au final cela force à faire les choses proprement et l'impact sur le logiciel final est évident. Enfin une autre bonne pratique est que quand je découvre un bug, je ne me jette pas dessus pour faire un correctif. Je cherche d'abord à le reproduire/isoler dans un test unitaire. Une fois cette étape faite, je peux apporter la correction. J'évite ainsi à l'avenir les régressions. Cela peut sembler contraignant voir inutile pour certains, mais cela paie systématiquement quand un projet prend de la taille.
Il serait également stupide de croire que les tests unitaires sont inutiles pour de petits projets. Le temps passé sur les tests lors de la conception (les tests ça ne s'écrit pas après sinon c'est inutile) est largement compensé au final car on converge plus vite vers un logiciel qui marche. Il faut essayer pour s'en rendre compte, ça ne semble pas évident de prime abord ...
Pas mal de techniques récentes intègrent cette notion. Je pense en particulier à l'IoC (Inversion of Control) qui permet l'obtention d'assemblages modulaires de composants découplés. Du coup ces composants sont très simples à tester. Le logiciel est ainsi meilleur.
Enfin il faudrait arrêter de prendre les systèmes de rapport de bugs comme des outils ultimes. Les utilisateurs sont là pour utiliser un logiciel, pas pour chercher dans le code la raison d'un bug. Si certains le font c'est tant mieux, mais la majorité ne le fera pas. Quand on critique MS qui prend ses utilisateurs pour des testeurs tout le monde trouve ça normal, mais quand c'est pour un logiciel libre, tout le monde dit : "envoie un rapport de bug et un patch si possible"...