Or, plus un code est factorisé, plus il est utilisé, et ses bugs sont donc d'autant plus rapidement détectés et corrigés. Ce qui rend probablement les tests superflus dans mon cas.
Mais en fait tes bugs, tu les découvres comment ?
À la compilation et à l’exécution ?
Je suis un peu dans ton cas, je ne code que seul et sur des projets que je suis le seul à utiliser ou presque. J'ai codé longtemps sans tests et ça m'allait, avec le cercle typique de Code/Compile/Essai. Mais même si comme tu le dis, on mets tout dans des fonctions sans effet de bord, des libs, (c'est la base tout ça en fait), des tests ça va grandement aider à savoir ce que tu attend d'une fonction, les paramètres d'entrés, tous ça. Tu peux faire une modif à 20 functions de profondeur dans ton code sans te rendre compte que tu retourne 5 à une entré qui va t'envoyer à une série de fonction et ça va peter quand dans certain cas tordu. Les tests peuvent empêcher cela. ça peut aider à ne pas avoir le cycle Code/Compile/Essai qui ne couvre rien en fait.
[^] # Re: Faire des tests, c'est bien, mais...
Posté par kowalsky . En réponse au journal Faites des tests !. Évalué à 4.
Mais en fait tes bugs, tu les découvres comment ?
À la compilation et à l’exécution ?
Je suis un peu dans ton cas, je ne code que seul et sur des projets que je suis le seul à utiliser ou presque. J'ai codé longtemps sans tests et ça m'allait, avec le cercle typique de Code/Compile/Essai. Mais même si comme tu le dis, on mets tout dans des fonctions sans effet de bord, des libs, (c'est la base tout ça en fait), des tests ça va grandement aider à savoir ce que tu attend d'une fonction, les paramètres d'entrés, tous ça. Tu peux faire une modif à 20 functions de profondeur dans ton code sans te rendre compte que tu retourne 5 à une entré qui va t'envoyer à une série de fonction et ça va peter quand dans certain cas tordu. Les tests peuvent empêcher cela. ça peut aider à ne pas avoir le cycle Code/Compile/Essai qui ne couvre rien en fait.