C'est le point de vue de Uncle Bob, et je suis assez d'accord avec lui.
Si tu n'as pas d'automatisation de tes tests, ça veut dire que tu les fais à la main. Ton cycle de feedback (entre modification du code et vérification) est potentiellement très long, et tu n'as aucune garantie que la couverture soit suffisante. Effectuer ce test à la main c'est de l'amateurisme, c'est pour moi parfaitement indiscutable, c'est du même ordre que réinventer la roue en permanence (ne pas utiliser de librairies ou de frameworks), c'est même pire puisqu'on fait manuellement des opérations qui sont automatisables facilement. Bref c'est une perte de temps sèche et également une absence de qualité indigne d'un pro.
Je sais bien que tout le monde n'est pas d'accord sur ça, il suffit de voir le ratio +1/-1 sur mon post initial pour s'en convaincre. Et c'est encore bien pire chez les décideurs qui ont une culture du développement logiciel très superficielle (pour rester poli).
Les TU remplissent un besoin précis : S'assurer que le code produit fait ce qu'il est censé faire, et avoir de la visibilité sur ce statut dans le temps. En exécutant une seule commande, on peut savoir si le code fait ce qu'il est censé faire ou pas. Cela permet donc le refactoring en limitant drastiquement les risques de régression. Évidemment cela suppose que les TU soient de bonne qualité.
Maintenant faire communiquer un système avec un autre (se connecter à une BDD, se connecter à une autre application via un WS, etc ...) ça ne peut évidemment pas être couvert par un test unitaire puisque le propre du test unitaire c'est de mocker tout le contexte autour du bloc de code à tester.
Pour ça on a les tests d'intégration qui ont pour rôle de tester que le cas passant entre 2 systèmes fonctionne. Bref, à besoin différent, solution différente
Partager