C'est possible de se passer de tests unitaires dans certains cas particulier comme celui décrit par Claude Simon, mais c'est un cas bien idéal, à savoir un code qui n'est manipulé que par une seule personne.
Dans 90% des cas, un code est amené à être modifié par un autre développeur que celui qui l'a écrit.
Une batterie de tests unitaires devient alors un outil indispensable pour un mainteneur afin de garantir que la rétrocompatibilité n'est pas cassée lors d'une modification, d'un refacto ou même simplement une correction de bug.
Dans des applications développées de manière itérative, il est souvent conseillé lors de la correction d'un bug, d'écrire un test qui échoue lorsque le bug est présent puis de réparer le bug et de valider la correction à l'aide de ce test unitaire.
Les tests unitaires permettent aussi à peu de frais de vérifier qu'un algorithme ou qu'une fonction marche dans des cas limite (entrée de taille nulle, entiers avec des valeurs de type MAX_INT, MIN_INT, etc).
Je pense que toi, Claude Simon, et d'après ce que tu dis, tu es parvenu à factoriser ton code de telle sorte que si un bug existait dans une de tes librairies, tu le détecterai automatiquement. C'est une bonne chose d'écrire avec un tel principe, c'est un des piliers d'un code de très bonne qualité de code (DRY = Don't Repeat Yourself). Dans ce cas, tu dois pouvoir te permettre de tester tes softs de manière plus intégrées (pas les libs en elle même mais le comportement des applications en situations réelles).
L'intérêt des tests unitaires / d'intégration c'est surtout de pouvoir automatiser les sessions de test et d'avoir un point de vue global sur l'état d'un projet.
[^] # Re: Faire des tests, c'est bien, mais...
Posté par nlhss . En réponse au journal Faites des tests !. Évalué à 3.
C'est possible de se passer de tests unitaires dans certains cas particulier comme celui décrit par Claude Simon, mais c'est un cas bien idéal, à savoir un code qui n'est manipulé que par une seule personne.
Dans 90% des cas, un code est amené à être modifié par un autre développeur que celui qui l'a écrit.
Une batterie de tests unitaires devient alors un outil indispensable pour un mainteneur afin de garantir que la rétrocompatibilité n'est pas cassée lors d'une modification, d'un refacto ou même simplement une correction de bug.
Dans des applications développées de manière itérative, il est souvent conseillé lors de la correction d'un bug, d'écrire un test qui échoue lorsque le bug est présent puis de réparer le bug et de valider la correction à l'aide de ce test unitaire.
Les tests unitaires permettent aussi à peu de frais de vérifier qu'un algorithme ou qu'une fonction marche dans des cas limite (entrée de taille nulle, entiers avec des valeurs de type MAX_INT, MIN_INT, etc).
Je pense que toi, Claude Simon, et d'après ce que tu dis, tu es parvenu à factoriser ton code de telle sorte que si un bug existait dans une de tes librairies, tu le détecterai automatiquement. C'est une bonne chose d'écrire avec un tel principe, c'est un des piliers d'un code de très bonne qualité de code (DRY = Don't Repeat Yourself). Dans ce cas, tu dois pouvoir te permettre de tester tes softs de manière plus intégrées (pas les libs en elle même mais le comportement des applications en situations réelles).
L'intérêt des tests unitaires / d'intégration c'est surtout de pouvoir automatiser les sessions de test et d'avoir un point de vue global sur l'état d'un projet.