À partir du moment où l’on commence à utiliser des classes, que ce soient les nôtres ou celles d’un toolkit/framework, nous avons des dépendances. Dans ce chapitre, nous allons voir pourquoi et comment les gérer.
Pourquoi gérer ses dépendances ?
La plupart de nos applications sont pleines de dépendances. Par exemple, imaginons une application qui a besoin d’aller récupérer la météo du jour, en allant la lire sur une API web ou dans une base de données. Si nous voulons tester notre application et notamment la partie météo, nous allons être dépendants du temps qu’il fait. Si je veux vérifier qu’il y a bien un soleil qui s’affiche lorsqu’il fait beau, dois-je vraiment attendre le bon jour pour pouvoir le vérifier ? Et si je crée un test automatique, il échouera les jours où il pleut ?
Ce n’est pas envisageable ! Un test doit être prédictif et idempotent, afin de pouvoir lui faire confiance. Si l'on ne peut pas faire confiance à notre base de tests que les jours où il fait beau, cela va devenir compliqué. 😎
Concrètement, cela veut dire que, si j’ai un test qui crée un client et qui vérifie que cela s’est bien passé, alors la fois suivante, il ne doit pas échouer parce que le client existe déjà. De la même façon, si un test me renvoie une liste de clients et qu’il y en a 10, mon test ne doit pas échouer s'il y en a 11 le lendemain !
De la même façon, certaines dépendances peuvent être très complexes à mettre en place. Par exemple, imaginons que nous tentions de prédire la météo par nous-mêmes. Une telle prévision nécessite probablement beaucoup de matériel et des calculs très complexes.
Difficile d’envisager de construire toute cette infrastructure très complexe et très coûteuse, juste pour vérifier qu’un soleil s’affiche bien quand il fait beau.
La solution est donc de remplacer cette lourde dépendance par une fausse, juste le temps des tests automatiques, pour vérifier qu’un soleil s’affiche. 😉
Cela peut se faire de plusieurs façons :
soit en écrivant une fausse classe simulant ce comportement ;
soit en utilisant un framework de simulacres.
Les frameworks de simulacre
Un framework de simulacre permet de bouchonner le code dont notre développement dépend afin de pouvoir le tester unitairement, sans dépendance et isolé du reste du système.
Cela veut dire que, dans notre test, nous allons remplacer la lecture de cette information complexe par une fausse méthode qui renvoie toujours qu’il fait beau. Cependant, ceci doit se faire sans modifier notre application, sinon cela n’a pas d’intérêt. Voilà à quoi servent ces frameworks de simulacre.
Il en existe plusieurs, plus ou moins complexes. Citons par exemple Moq (prononcez « moque-you ») qui est un framework open source et gratuit. Certains sont payants et fournissent des outils très puissants lorsqu’il s’agit de tester du code legacy qui a été écrit sans penser à la testabilité.
L’intérêt de Moq est qu’il est simple d’accès et qu'il est gratuit. Je le présenterai dans la prochaine partie, quand nous rentrerons dans le concret de l’écriture de tests. Encore un peu de patience ! ;)
Les différents types de bouchons
En entreprise ou dans des articles sur internet, vous allez très souvent voir le terme "bouchon" pour indiquer quelque chose qui va simuler un comportement.
Pour être précis, il faudrait utiliser le terme doublure de test, que l’on trouve plus fréquemment en anglais avec la terminologie “tests doubles”.
Il existe plusieurs types de doublures de tests, dont notamment les bouchons et les simulacres (en anglais respectivement stubs et mocks). Il existe aussi le concept de fantôme(dummy) et de substitut(fake).
Il est très facile de mélanger les différents termes et d’abuser un peu de la terminologie. Beaucoup de personnes utilisent les différents mots de manière interchangeable. Ce n’est pas trop grave lorsque l’on débute, mais chaque type de doublure de test a un but précis, dont la différence peut être parfois subtile.
Quand vous aurez de l’expérience avec les tests, vous y reviendrez naturellement. Ce qui est important pour vous, aujourd’hui, c’est de comprendre que le but final d’une doublure de test est de simuler des dépendances (que ce soient un composant complet, une classe, une méthode, etc.) afin de simplifier l’écriture des tests.
Ce chapitre vous paraît abstrait ? Ne vous inquiétez pas, nous allons pratiquer très bientôt !
