Que pouvez-vous faire de la qualité des tests d'intégration et d'unité existants tout en étant le nouveau gars dans une équipe?

Question

Un thème récurrent que j'ai rencontré dans ma carrière est le nouveau développeur à arriver dans une équipe, et avoir rapidement une méfiance inhérente à l'unité existante et aux suites de test d'intégration.

Au cours de l'entretien, la direction vous dit qu'elle "soutient fortement les tests unitaires" et qu'ils l'encouragent ouvertement. Ils le font, mais tout sur les tests eux-mêmes est tout simplement faux. Comme le fait qu'ils réclament une couverture à 100% lorsqu'il y a une couverture de test d'intégration à 100% mais moins de 10% de couverture de test unitaire répétable. Quelques autres problèmes que j'ai trouvés:

1. Aucune indication claire entre ce qui est un test unitaire et ce qui est un test d'intégration. Les tests d'unité et d'intégration sont mélangés dans la même classe.

2. Des 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.

3. Des 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 la base de données manuelle de «nettoyage» pour rendre le test reproductible.

4. Aucune moquerie, et le code d'application nécessite une refonte majeure juste pour que la moquerie soit possible. En d'autres termes, concevoir sans tester à l'esprit.

5. Pas de conventions de dénomination claires pour examiner rapidement un nom de test et déterminer à peu près quels tests sont effectués.

Tout cela ne veut pas dire que tous les tests sont inutiles ou mauvais, beaucoup d'entre eux sont assez bons et qui valent la peine d'être conservés, mais cela ressemble parfois à un panoramique pour l'or. J'éviterais délibérément des tests simplement parce que j'avais peur de baiser la base de données pour mes cas de test de boîte noire.

Cela m'a essentiellement donné un inhérent méfiance des tests d'unité et d'intégration que je n'ai pas écrits ou examinés personnellement d'une manière ou d'une autre. À un certain niveau, si vous n'avez pas confiance dans 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 les versions? Devriez-vous simplement abandonner l'idée que ce projet hérité peut avoir une couverture de test unitaire solide d'un jour?