Je n'écris pas de tests unitaires. [...]
Seulement, je n'ai pas le temps. Le fait est que je factorise mon code le plus possible, ce qui fait que les bugs sont très vite détectés, et donc corrigés, lors de l'utilisation courante du code incriminé.
Pourtant ça en fait gagner, du temps ;-)
Bien sûr, au début quand on n'est pas habitué à écrire des tests, ça prend un certain temps, c'est comme pour tout. Mais un bug découvert en développement coûte moins cher que s'il est découvert plus tard (en validation ou chez le client).
Quand on développe, on ne pense pas forcément à tous les cas qui peuvent survenir (cas nominaux comme cas d'erreurs). Par contre, quand on écrit des tests, on y pense plus facilement vu qu'on va essayer de retourner le soft dans tous les sens (on essaie d'imaginer toutes les combinaisons possibles en entrée). Et donc on peut revenir sur son code et colmater les cas oubliés. Sans compter les trucs dont on se dit « c'est trivial, ça ne peut que marcher » puis l'on se rend compte en testant que non, c'est quand même buggué... Maintenant, je considère carrément que du code non testé c'est du code qui ne marche pas (et j'ai déjà la ceinture et les bretelles grâce à Ada).
À une époque, sur un projet, on a tenté la production rapide sans tests (on code un truc puis on le valide immédiatement en plateforme intégrée), mais on a fini par abandonner, ça coûtait plus cher au final : régressions dans tous les sens (« ah merde, ça touche ça aussi ? »), tests à la con non passés car plus difficiles une fois tout intégré, qualité du soft moins bonne. Je faisais notamment beaucoup de factorisation de code aussi ;-)
Quand tu as un soft avec énormément de fonctionnalités, une bonne batterie de tests unitaires c'est redoutable contre les régressions. Ça me permet de coder plus vite, puisque je passe moins de temps à tout vérifier 3 fois avant de passer le bulldozer dans le code. Je vérifie une fois, puis si je casse des choses, les tests me le révéleront très vite.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Meku (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 6.
Pourtant ça en fait gagner, du temps ;-)
Bien sûr, au début quand on n'est pas habitué à écrire des tests, ça prend un certain temps, c'est comme pour tout. Mais un bug découvert en développement coûte moins cher que s'il est découvert plus tard (en validation ou chez le client).
Quand on développe, on ne pense pas forcément à tous les cas qui peuvent survenir (cas nominaux comme cas d'erreurs). Par contre, quand on écrit des tests, on y pense plus facilement vu qu'on va essayer de retourner le soft dans tous les sens (on essaie d'imaginer toutes les combinaisons possibles en entrée). Et donc on peut revenir sur son code et colmater les cas oubliés. Sans compter les trucs dont on se dit « c'est trivial, ça ne peut que marcher » puis l'on se rend compte en testant que non, c'est quand même buggué... Maintenant, je considère carrément que du code non testé c'est du code qui ne marche pas (et j'ai déjà la ceinture et les bretelles grâce à Ada).
À une époque, sur un projet, on a tenté la production rapide sans tests (on code un truc puis on le valide immédiatement en plateforme intégrée), mais on a fini par abandonner, ça coûtait plus cher au final : régressions dans tous les sens (« ah merde, ça touche ça aussi ? »), tests à la con non passés car plus difficiles une fois tout intégré, qualité du soft moins bonne. Je faisais notamment beaucoup de factorisation de code aussi ;-)
Quand tu as un soft avec énormément de fonctionnalités, une bonne batterie de tests unitaires c'est redoutable contre les régressions. Ça me permet de coder plus vite, puisque je passe moins de temps à tout vérifier 3 fois avant de passer le bulldozer dans le code. Je vérifie une fois, puis si je casse des choses, les tests me le révéleront très vite.