Un thème récurrent que j'ai rencontré dans ma carrière est d'être le nouveau développeur à arriver dans une équipe et d'avoir rapidement une méfiance inhérente envers les suites de tests unitaires et d'intégration existantes.
Au cours de l'entretien, la direction vous dit qu'elle "soutient fortement les tests unitaires" et qu'elle les encourage ouvertement. Ils le font, mais tout ce qui concerne les tests eux-mêmes est tout simplement faux. Comme le fait qu'ils revendiquent une couverture de 100% alors qu'il y a une couverture de test d'intégration de 100% mais une couverture de test unitaire répétable inférieure à 10%. Quelques autres problèmes que j'ai trouvés:
Aucune indication claire entre ce qu'est un test unitaire et ce qu'est un test d'intégration. Les tests unitaires et d'intégration sont mélangés dans la même classe.
Tests d'intégration qui ont des dépendances explicites non déclarées sur des données dynamiques très spécifiques sur la base de données d'un environnement spécifique.
Tests d'intégration non transactionnels, essentiellement des tests qui peuvent ou non prendre la peine de nettoyer après eux-mêmes, nécessitant parfois un "nettoyage" manuel de la base de données pour rendre le test reproductible.
Aucune moquerie du tout, et le code d'application nécessite une refonte majeure juste pour que la moquerie soit possible. En d'autres termes, concevoir sans tester en tête.
Pas de conventions de dénomination claires pour examiner rapidement un nom de test et déterminer approximativement quels tests sont effectués.
Cela ne veut pas dire que TOUS les tests sont inutiles ou mauvais, beaucoup d'entre eux sont assez bons et valent la peine d'être conservés, mais on a parfois l'impression de chercher de l'or. J'éviterais volontairement d'exécuter des tests simplement parce que j'avais peur de bousiller la base de données pour mes cas de test de boîte noire.
Cela m'a essentiellement donné une méfiance inhérente aux tests unitaires et d'intégration que je n'ai pas personnellement écrits ou passés en revue d'une manière ou d'une autre. À un certain niveau, si vous n'avez pas confiance en la qualité de votre suite de tests, cela n'apporte vraiment aucune valeur à l'équipe ou au projet.
Que faites-vous lorsque vous vous trouvez dans cette situation? Selon vous, quel serait le meilleur plan d'attaque pour s'attaquer à quelque chose comme ça?
Tous les tests devraient-ils être refactorisés dans un effort monumental s'étendant sur plusieurs versions? Devriez-vous simplement abandonner l'idée que ce projet hérité peut avoir une couverture de test unitaire solide d'un jour?