Quels sont les avantages tangibles des tests unitaires appropriés par rapport aux tests fonctionnels appelés tests unitaires

Un projet sur lequel je travaille a un tas de tests hérités qui n'ont pas été correctement simulés. Pour cette raison, la seule dépendance dont il dispose est EasyMock, qui ne prend pas en charge la statique, les constructeurs avec des arguments, etc. L'ajout de powermock pour gérer ces cas est considéré comme un coût prohibitif en raison de la nécessité de mettre à niveau le projet existant pour le soutenir (une autre discussion).

Mes questions sont, quels sont les avantages tangibles du monde réel de tests unitaires appropriés que je peux utiliser pour repousser? Y a-t-il? Suis-je juste un bâton en disant que les mauvais tests unitaires (même s'ils fonctionnent) sont mauvais? La couverture du code est-elle tout aussi efficace?

• Ressources

  Vous avez besoin d'une base de données de test pour exécuter les tests. Le matériel pour exécuter la base de données est plus cher que l'utilisation de Powermock. La libération des ressources utilisées pour les tests unitaires par rapport à la base de données signifie que l'entreprise n'a pas besoin de mettre à niveau le serveur dès que possible.

• Fiabilité

  Un test peut échouer car la base de données est en panne ou dans un état incohérent. Devinez quoi, vos versions ont échoué parce que les administrateurs de bases de données ont arrêté le serveur de développement pendant la journée pour effectuer certaines mises à niveau (et maintenant les développeurs tentent de comprendre ce qui a mal tourné dans le code - quand ce n'est pas le code).

• Maintenance supplémentaire

  Les tests peuvent être exécutés dans n'importe quel ordre. L'ajout ou la suppression d'un test ne doit pas entraîner l'échec de la suite de tests. L'exécution contre une base de données signifie qu'il y a un état quelque part (dans la base de données). En règle générale, ces tests nécessitent une maintenance supplémentaire pour garantir que la base de données conserve l'état approprié pour l'exécution du test suivant.

• Accès simultané

  Deux développeurs exécutent les tests unitaires en même temps. Avoir une base de données signifie que les tests peuvent entrer en collision avec la base de données. La solution serait de cloner la base de données pour chaque test exécuté, ce qui est prohibitif sur une vraie base de données. Ce qui conduit à une autre option à considérer.

Pensez également à utiliser HSQLDB avec le dialecte de base de données que vous utilisez. De cette façon, on peut créer une base de données en mémoire pour chaque test. Un test unitaire s'exécute, construit la base de données nécessaire, charge les données, la connexion à la base de données à partir du code se connecte à HSQLDB et s'exécute sur les données de test.

Mes questions sont, quels sont les avantages tangibles du monde réel de tests unitaires appropriés que je peux utiliser pour repousser?

Les bons tests unitaires sont (par Clean Code et ailleurs):

• Vite
• Indépendant
• Répétable
• Auto-validation
• Opportun

Ne pas avoir de vrais tests unitaires viole les trois premiers (et généralement le dernier). Cela conduit à des problèmes assez importants:

1. Vos tests sont lents. Les tests lents sont rarement exécutés. Les tests qui ne sont pas exécutés sont presque inutiles.
2. Vos tests peuvent échouer pour des raisons sans rapport avec le code que vous testez. Cela rend beaucoup plus difficile de savoir pourquoi les tests ont échoué, ce qui fait perdre du temps et incite les gens à blâmer l'environnement plutôt que le code.
3. À mesure que la base de données change, vos résultats changent. Obtenir une base de données dans un bon état connu et cohérent pour les tests est fastidieux, ennuyeux et sujet aux erreurs.

En général, un manque d'isolement dans les tests unitaires conduit à de pires tests qui prennent plus de temps à écrire, à investir et à donner moins confiance à votre base de code. Cela conduit à son tour les gens à écrire moins de tests ou à ignorer davantage les tests, ce qui est la spirale descendante du chaos.

Les tests unitaires ne sont qu'un outil utilisé pour aider un développeur à fournir un code fiable. Si vous pensez comme le pense votre patron, vous pourrez le convaincre si ce que vous proposez a du sens. Cependant, si vous le présentez en tant qu'évangéliste sur un chariot de bande, vous n'obtiendrez pas les ressources allouées. Vous devrez lui expliquer ses avantages en passant du temps et des ressources à adapter les tests unitaires à votre ancienne application.

Vous avez mentionné les tests hérités - cela implique du code hérité. Malheureusement, adapter des tests unitaires à du code qui n'a pas été conçu pour être testé à l'unité est un processus difficile, long et coûteux. L'analyse de rentabilisation devient encore plus difficile si vous avez des tests qui fournissent des résultats utiles, et tout ce que vous allez réaliser est (à partir du PDV de l'analyse de rentabilisation) des tests alternatifs fournissant les mêmes résultats. Vous devrez vous concentrer sur les économies de coûts (temps) .....

Je suppose que vous ne pourrez pas présenter à votre patron une solide analyse de rentabilisation, car il n'y en a pas.

D'après ce que vous avez décrit, il semble que vous n'aimiez pas le cadre de test A et que vous souhaitiez passer au cadre de test B, qui fonctionnent tous les deux. Aspirez-le et utilisez ce qui existe et fonctionne, ne créez pas plus de travail en réinventant la roue afin que vous puissiez utiliser votre cadre de test préféré.

Il faut plus que vouloir utiliser la dernière version du cadre du mois pour justifier de jeter le code de travail existant et de dépenser énormément de temps et d'argent pour un bénéfice essentiellement nul pour les utilisateurs.

De bons tests unitaires permettent la localisation. Les tests fonctionnels peuvent vous dire "la fonction d'ajout d'utilisateur est cassée", mais un bon test unitaire vous dira qu'elle est cassée parce que quelqu'un a changé le champ USER.LAST_NAME dans la base de données pour qu'il soit non nul. Il est également possible de tester directement de petits changements, au lieu d'avoir besoin d'un environnement de test complexe (qui peut avoir besoin d'être réinitialisé ou purgé pour certains tests).