Faire des tests unitaires est presque une religion, mais quels sont les réels avantages ? L’infographie ci-dessous y répond aussi simplement que possible. Sachez que celle-ci a été créée par Typemock, la firme n’était donc pas complètement impartiale… En effet, la société propose des outils de test unitaire et des astuces pour écrire des tests en .NET et C/C++, permettant un développement agile.
Pour ceux qui ne sont pas vraiment à l’aise avec la définition d’un test unitaire, je vous recommande de lire un article que j’avais rédigé il y a de cela quelques mois. Dans celui-ci je vous présentais le sujet avec des exemples concrets ! Depuis, cette pratique s’est nettement répandue. Qui n’a jamais développé un projet depuis de nombreuses heures en ayant l’impression de tourner en rond ? Corriger un bug, un autre, puis un autre … Un rituel quotidien entre le débogage par l’actualisation du site Web, la déclaration d’un bon nombre de trace. Toutes les méthodes sont bonnes pour réussir. Malheureusement, ne vous êtes vous jamais demandé s’il y avait une meilleure façon de faire ?
Il y en a une, et elle n’est pas aussi difficile que vous pourriez le penser. Faire des tests unitaires de votre application ne vous fera pas seulement réduire certains maux de tête que vous pourriez avoir pendant le développement, mais il peut aboutir à un code plus facile à maintenir, vous permettant de faire des changements plus audacieux (comme modification majeure) sans hésitation.
Même si l’infographie dévoilée ci-dessous ne met en avant que le côté positif de la chose, il faut admettre qu’il y a beaucoup de points positifs !
Les tests unitaires vont de pair avec toutes les saveurs de la programmation agile, et parce qu’ils permettent de construire des tests dans le but de faire des changements plus facilement. En d’autres termes, les tests unitaires facilitent bien sûr la refactorisation.
L’idée est simple : écrire quelques lignes de code supplémentaires qui effectuent des tests vérifiant un bloc de code en particulier – presque toujours une fonction ou une méthode – se comporte correctement. Dès que cette étape est réalisée, vous pouvez dès lors travailler sur le bloc en question jusqu’à ce qu’il passe tous les tests.
Si plus tard vous décidez que le bloc doit être changé, autrement dit remanié, les tests indiqueront immédiatement si vous avez fait une erreur. De quoi éviter la non régression, le mal ultime de tous les développeurs !
Le refactoring sans mettre en place des tests unitaires est dangereux car dès lors que vous réécrire une partie de la méthode, d’une boucle, potentiellement vous pouvez engendrer des dizaines d’erreurs, et elles seront très difficiles à déceler.
Il est également affirmé que les tests unitaires forment une sorte de documentation “live” sur ce que les blocs de code sont censés faire. Si c’est plutôt vrai, il s’agit bien sûr d’un faible niveau de documentation et ce n’est pas une raison de ne pas en écrire une.
Mais, le gros problème avec les tests unitaires, c’est qu’il y a beaucoup plus de code. Et, je suppose que vous devez vous poser la question, de qui ou quoi je dois tester avec ces tests unitaires ? Si cette question peut paraître idiote, bien au contraire … En effet, celle-ci est pourtant primordiale, mais est omise par beaucoup de développeurs.
Nous avons tendance à ignorer que le simple fait de faire de la refactorisation va souvent non seulement perturber la structure du programme, mais également celle des tests.
En bref, les tests unitaires sont mieux que rien, et s’avère être bien plus efficace que d’ajouter des portions de code de test dans une méthode. Reste à trouver des outils performants pour effectuer ce travail …
Avez-vous mis en place des tests unitaires dans vos applications, dans vos méthodes de développement ? Quels outils utilisez-vous ?
