Pourquoi isoler vos tests unitaires est important

Les développeurs isolent déjà leur code, même lorsqu’ils n’exécutent pas de tests unitaires, car cela leur permet d’en faire plus en moins de temps. Adopter l’isolement lors des tests présente ces avantages et bien plus : un meilleur code, un développement plus rapide et des versions plus fiables.

Les développeurs isolent déjà leur code, même si ce n’est pas quelque chose dont ils s’inquiètent lorsqu’ils exécutent des tests unitaires. Lorsqu’un développeur débogue une application, par exemple, il exécutera probablement son code sur une copie locale de la base de données de l’application. Non seulement cela accélère l’exécution de l’application lors du débogage (ou des tests), mais cela garantit également que personne ne gâche les données de test qu’il a accumulées au fil du temps.

En fait, la plupart des développeurs déboguent également leurs applications sur un serveur Web local et, idéalement, ont installé tous les services Web associés sur ce serveur local. Si ce n’est pas le cas, ils appellent une version « développement » de ces services Web (si, pour aucune autre raison, parce que personne ne veut que le code de test soit mis à jour vers la version « production » des services).

Mais si tout le monde avait ce qu’il voulait, les développeurs utiliseraient des copies locales de tout ce avec quoi leur code interagit : ils s’exécuteraient sur des services locaux, sur un serveur Web local, et utiliseraient une base de données locale pour leur code et les services qu’ils appellent. Les ressources locales et isolées offrent aux développeurs à la fois rapidité et indépendance.

Bien sûr, cela nécessite un moyen de maintenir cet environnement. Le problème avec l’exécution du code de développement, par exemple, est qu’il modifie vos données et, généralement, pas dans le bon sens. C’est toujours embarrassant, par exemple, lorsqu’une opération de suppression devient malveillante et efface toutes vos données de test.

Pour gérer cela, les développeurs disposent de plusieurs outils pour réinitialiser l’environnement de développement. Pour les données de test, il peut s’agir de sauvegardes de la base de données qui peuvent être utilisées pour restaurer à une « étape zéro ». Alternativement, le code de développement peut tirer parti des options d’initialisation d’Entity Framework pour recréer cette « étape zéro » au démarrage du code. D’autres ressources peuvent inclure des scripts PowerShell qui recréent l’environnement de test ou des modèles Azure qui recréent des ressources cloud.

Essentiellement, ces outils isolent le code dans le temps. Peu importe ce qui s’est passé avant que le code ne commence à s’exécuter, car une session de débogage commence toujours à partir d’une « étape zéro » bien définie. Idéalement, il y a une seule action qui fait tout le nécessaire pour isoler le code de développement de tout ce qui s’est passé avant que le code ne commence à s’exécuter (et, idéalement, une action qui se produit automatiquement lorsque le code démarre car, avouons-le, tout le monde oublie parfois d’effectuer une restauration vers « Étape zéro »).

Tester n’est pas déboguer

La création d’un environnement de développement local a autant de sens pour les tests unitaires que pour le code. Mais la différence entre les tests et le débogage est que, lors du développement de code, vous n’avez pas toujours besoin d’une réponse « parfaite », donc la réinitialisation à « l’étape zéro » n’est pas toujours nécessaire.

Souvent, lors du débogage, vous êtes satisfait si votre code s’exécute jusqu’à la fin – vous travaillez sur une zone spécifique du code plutôt que d’enquêter sur une transaction complète. Parfois, vous n’avez peut-être même pas l’intention de laisser votre code s’exécuter jusqu’à la fin : vous souhaitez simplement trouver où se situe un problème afin de pouvoir arrêter votre code et résoudre le problème.

Les tests sont différents. Chaque test unitaire doit être complètement isolé de tout autre test unitaire car, à chaque test, vous avez besoin d’une réponse parfaite : le code fonctionne-t-il ou non ? Vous pouvez savoir si vos tests sont isolés en posant une seule question : l’ordre dans lequel vous exécutez vos tests modifie-t-il le résultat des tests ? Si la réponse est « Non », vos tests sont vraiment isolés les uns des autres.

Comme pour isoler votre code, isoler vos tests présente de réels avantages. Entre autres choses, isoler vos tests vous simplifie considérablement la vie. Si l’ordre dans lequel vous exécutez vos tests est important, vous devez gérer l’ordre de vos tests. Si l’ordre n’a pas d’importance, vous pouvez exécuter n’importe quel test (ou ensemble de tests) sans avoir à y penser.

Si vous allez plus loin et que vous pouvez également recréer l’environnement dans lequel vos tests s’exécutent (services de base de données et Web et tout ce qui compte), vous obtenez un avantage supplémentaire : cela n’a pas d’importance. où vous exécutez vos tests, non plus. Vous pouvez recréer votre environnement de test sur n’importe quel ordinateur chaque fois que vous souhaitez exécuter votre test. Effectivement, alors, vous avez également isolé vos tests dans l’espace. Pour atteindre cet objectif, en plus de vos scripts PowerShell, des sauvegardes de base de données, etc., vous pouvez également inclure des packages de déploiement pour les services Web utilisés par le CUT (code en cours de test).

L’objectif d’isoler vos tests dans le temps et dans l’espace est de créer écurie tests : tests qui donnent les mêmes résultats, peu importe quand ils sont exécutés, où ils sont exécutés, dans quel ordre ils sont exécutés et quoi d’autre se passe en même temps. Créer des tests stables n’est pas anodin (si vous ne pensez pas déjà aux conteneurs, c’est peut-être le bon moment pour commencer). Mais ce n’est pas non plus difficile à faire et il y a de réels avantages à tirer de la création de tests stables.

Les avantages de l’isolement

Le premier avantage est l’aide à l’identification des bugs. Si vos tests sont isolés à la fois dans le temps et dans l’espace, alors, si un test échoue, ce doit être à cause du code que le test exerce… et ce sera à cause de quelque chose qui a été fait depuis la dernière fois que les tests ont été exécutés (il y a un incitation à exécuter vos tests fréquemment).

En d’autres termes, le code qui est « en tête » en ce moment est le code qui fait échouer les tests. Couplée aux bonnes pratiques pour nommer les tests, souvent, la simple lecture du nom d’un test défaillant déclenchera une compréhension de ce qui cause l’échec du test. Trouver des bogues plus rapidement signifie fournir du code plus rapidement.

Si plusieurs tests échouent, cela doit être dû à quelque chose que ces tests partagent. Et c’est une odeur de code : si vous ne pouvez pas isoler vos tests, c’est un signe que le code est probablement trop étroitement couplé. L’écriture de tests unitaires isolés oblige les développeurs à penser à créer du code faiblement couplé, c’est-à-dire un code plus flexible, réutilisable et résilient.

Et, en isolant vos tests sur les plates-formes sur lesquelles vous exécutez vos tests, vous avez également documenté à quoi votre environnement de production doit ressembler, en supposant, c’est-à-dire que vous voulez que votre code s’exécute aussi bien en production qu’en test ( et vous faites). Les outils qui isolent vos tests vous permettent de créer, en production, le même environnement qui a permis à votre code de s’exécuter avec succès en test.

Ce que l’isolement signifie vraiment, c’est que vous n’entendrez peut-être plus jamais les mots redoutés « Eh bien, cela a fonctionné lors du test ».

Isolation des tests unitaires avec cadre moqueur

Atteindre un isolement parfait n’est pas anodin, c’est-à-dire si vous essayez de tout faire par vous-même. La plupart des développeurs utilisent des frameworks de simulation, comme Telerik JustMock, pour créer des simulations pour les appels aux serveurs de base de données, aux services Web, aux bibliothèques tierces ou même à un autre morceau de leur propre code. En règle générale, il suffit d’une ou deux lignes de code ajoutées à la partie « organiser » de votre test pour isoler le composant que vous souhaitez tester.