Pour moi, l'écriture de tests fait partie intégrante du développement et code est tests sont inséparables. D'ailleurs, quand un chef insiste pour séparer tests et code en deux colonnes dans les chiffrages/planifications, je mets 0 dans l'une des deux (genre 0 dev et tout dans test pour choquer les esprits), histoire d'éviter d'entendre ensuite qu'on va pas faire de tests car c'est trop cher.
Remarque, faudrait que j'essaie un truc du style la colonne dev multipliée par deux (ou plus), et la colonne tests avec un nombre négatif pour retrancher la perte de temps à refaire le dev éternellement jusqu'à ce que ça marche en bout de chaîne.
De mon expérience, du code non testé c'est une chance sur deux pour que ça foire (même un truc très simple), donc de base je considère que du code non testé c'est du code qui ne marche pas (je parle pour mon code). Le nombre de fois où je me suis dis « ah c'est facile à corriger, juste une ligne, et tester ça me demande d'écrire un test... » et puis bah en fait, j'aurais dû l'écrire ce test, avant de livrer ma correction en bois...
J'ai testé avec et sans tests sur un même logiciel. Suite à de gros travaux d'architecture réalisés en urgence, j'avais perdu tous les tests (ils étaient mal écris et ça représentait un travail monstrueux pour les remettre d'équerre avec le changement d'architecture). Quand en plus j'ai dû faire du refactoring sur le logiciel, je provoquait des régressions à tout va qu'on ne voyait qu'en bout de chaîne, donc ça coûtait cher à reprendre (sans compter l'énervement du client et des valideurs, plus la perte de confiance à chaque nouvelle livraison). Un jour j'ai pris le temps (qu'on ne m'a pas donné, mais je l'ai pris quand même) de ré-écrire une bonne base de tests pour contrôler un peu ce que je livrais. Ça a stoppé net toutes les régressions, et m'a permis de reprendre un cycle de développement avec tests, ce qui a fait gagner beaucoup de temps par la suite. Bref, sans tests, le refactoring est impossible. Depuis cette expérience, j'ai la preuve formelle que pas de test = caca.
À noter qu'écrire du code testable (c'est-à-dire qu'on puisse tester facilement à 100%) mène à une conception différente (et plus propre) que quand on travaille à la rache, et ça sans augmenter le coût total du développement.
Enfin, les tests me permettent de dire « j'ai fini mon travail », car ils constituent une preuve de résultat.
# Le test fait partie intégrante du développement
Posté par Meku (site web personnel) . En réponse au journal Faites des tests !. Évalué à 10.
Pour moi, l'écriture de tests fait partie intégrante du développement et code est tests sont inséparables. D'ailleurs, quand un chef insiste pour séparer tests et code en deux colonnes dans les chiffrages/planifications, je mets 0 dans l'une des deux (genre 0 dev et tout dans test pour choquer les esprits), histoire d'éviter d'entendre ensuite qu'on va pas faire de tests car c'est trop cher.
Remarque, faudrait que j'essaie un truc du style la colonne dev multipliée par deux (ou plus), et la colonne tests avec un nombre négatif pour retrancher la perte de temps à refaire le dev éternellement jusqu'à ce que ça marche en bout de chaîne.
De mon expérience, du code non testé c'est une chance sur deux pour que ça foire (même un truc très simple), donc de base je considère que du code non testé c'est du code qui ne marche pas (je parle pour mon code). Le nombre de fois où je me suis dis « ah c'est facile à corriger, juste une ligne, et tester ça me demande d'écrire un test... » et puis bah en fait, j'aurais dû l'écrire ce test, avant de livrer ma correction en bois...
J'ai testé avec et sans tests sur un même logiciel. Suite à de gros travaux d'architecture réalisés en urgence, j'avais perdu tous les tests (ils étaient mal écris et ça représentait un travail monstrueux pour les remettre d'équerre avec le changement d'architecture). Quand en plus j'ai dû faire du refactoring sur le logiciel, je provoquait des régressions à tout va qu'on ne voyait qu'en bout de chaîne, donc ça coûtait cher à reprendre (sans compter l'énervement du client et des valideurs, plus la perte de confiance à chaque nouvelle livraison). Un jour j'ai pris le temps (qu'on ne m'a pas donné, mais je l'ai pris quand même) de ré-écrire une bonne base de tests pour contrôler un peu ce que je livrais. Ça a stoppé net toutes les régressions, et m'a permis de reprendre un cycle de développement avec tests, ce qui a fait gagner beaucoup de temps par la suite. Bref, sans tests, le refactoring est impossible. Depuis cette expérience, j'ai la preuve formelle que pas de test = caca.
À noter qu'écrire du code testable (c'est-à-dire qu'on puisse tester facilement à 100%) mène à une conception différente (et plus propre) que quand on travaille à la rache, et ça sans augmenter le coût total du développement.
Enfin, les tests me permettent de dire « j'ai fini mon travail », car ils constituent une preuve de résultat.