Maintenant que vous savez ce que sont les tests unitaires, tout votre être n'est plus animé que par une seule passion : les créer !
Je vous demande pourtant quelques petites minutes de patience. Je sais, c'est dur, mais avant de rédiger vos premiers tests, il faut se demander quels sont les éléments à tester !
Nous verrons donc la question du comment tester au chapitre suivant et pour l'heure concentrons-nous sur le quoi tester.
Tests et MVC
Comme tout développeur qui se respecte et qui maîtrise le MVC, vos applications sont toujours séparées en trois et votre modèle est bien isolé de la vue.
En MVC, la logique de l'application se situe dans le modèle. C'est donc le cerveau de l'application. Et il faut avant tout s'assurer que le cerveau fonctionne bien ! Donc, c'est le modèle que nous allons tester en MVC !
Et la vue ?
La vue est une entité extrêmement simple, elle n'effectue aucune logique. Elle affiche juste ce qu'on lui demande d'afficher. Donc on n'a pas besoin de tester la vue.
Et le contrôleur ? Lui, il contrôle la vue et donc il peut y avoir un peu de logique d'affichage à tester !
C'est bien vu ! Et c'est là que l'on atteint les limites du MVC. Vous verrez que pour des projets ambitieux, vos contrôleurs vont devenir énormes, car en fait le rôle du contrôleur est trop important.
Pour l'heure, nous allons rester en MVC et nous contenter de tester le modèle, ce qui est déjà suffisamment ambitieux pour le moment ! Mais gardez en tête que vous pouvez aller plus loin en explorant d'autres architectures.
Tests et classes
Dans notre modèle, nous avons trois classes : Game, Set et Match. Ce sont les trois classes que nous allons tester.
Le concept d'interface
Je vous ai expliqué qu'un test unitaire ne testait qu'une petite unité de code comme la méthode d'une classe.
OK j'ai compris ! Ça veut dire qu'on va tester toutes les méthodes de toutes les classes !
Vous vous rapprochez, mais ce n'est pas exactement ça. Vous vous souvenez : une classe permet de cacher une implémentation. Par exemple, ici, la logique complète de la classe Match ne nous intéresse pas. On veut juste pouvoir ajouter un point et récupérer le nouveau score.
Et bien, avec les tests on ne s'intéresse pas à la logique interne de la classe, mais seulement à ce qu'on appelle son interface, c'est-à-dire les propriétés et méthodes disponibles à l'extérieur de la classe.
Autrement dit, nous n'allons pas tester les méthodes et propriétés privées, mais seulement les méthodes et propriétés publiques.
Visualiser l'interface
Pour que le concept d'interface soit clair, je vous propose de vous montrer comment la visualiser avec Xcode.
Et c'est très simple ! Il vous suffit de sélectionner le fichier dont vous souhaitez visualiser l'interface, par exemple : Match.swift. Puis vous allez dans l'onglet Navigate et vous cliquez sur Jump to Generated Interface.
Ensuite, Xcode vous montre l'interface de votre classe :
Sur cette vue, vous pouvez voir l'ensemble des propriétés et méthodes de vos classes au niveau interne et public. Toutes les autres sont cachées. Et les implémentations des méthodes aussi.
Vous pouvez voir ici du coup qu'il existe une seule méthode publique à la classe match : la méthode pointEnded. Toutes les méthodes privées ne font pas partie de l'interface.
Tester uniquement les interfaces
En résumé, on teste uniquement les interfaces de nos classes. Autrement dit, quand on rédige un test on ne doit même pas savoir comment est construite la classe à l'intérieur. C'est la même chose que quand on travaille sur le contrôleur.
Mais du coup, on ne va pas tout tester !
Et si ! Les méthodes privées sont utilisées par les méthodes publiques. Donc lorsqu'on teste qu'une méthode publique fonctionne correctement, certaines méthodes privées sont appelées. Et finalement, l'ensemble de la classe est testée presque sans qu'on s'en rende compte !
Conditions pour tester
Les tests nous encouragent à nous concentrer sur les interfaces de nos classes et leurs organisations. En particulier, pour que notre code soit facilement testable, il faut suivre deux principes :
Responsabilité unique : Si une classe fait plusieurs choses à la fois, elle va devenir très grosse et du coup compliquée à tester. Lorsque vous créez une classe : assurez-vous qu'elle ne sert qu'à une seule chose.
Classes découplées : Imaginons que vous installiez dans votre application un service de paiement. Si ce service de paiement est intégré dans plusieurs classes, cela va rendre le test de ces classes compliquées. À la place, il vaut mieux créer une classe dédiée à la gestion du paiement pour garder les autres classes indépendantes de ce service et testables facilement. On appelle cela découpler les classes.
Et pour y arriver, souvenez-vous de créer des classes découplées à responsabilité unique !
Tests utiles
Enfin, ça paraît évident, mais ça va mieux en le disant, il faut créer des tests utiles.
Sans blague ?!
Oui j'enfonce un peu une porte ouverte, mais sauriez-vous me dire ce qu'est un test utile ?
Euh...
Vous voyez, ce n'est pas si évident ! Un test utile, c'est un test qui peut échouer et qui peut réussir. Autrement dit, un test qui échoue toujours est inutile, même chose pour un test qui ne peut que réussir.
Par exemple, ça ne sert à rien de tester que lorsque vous rajoutez un élément dans un tableau, la taille du tableau s'incrémente. Ce sera toujours bon (à moins que le langage Swift ne marche plus, mais là vous aurez d'autres problèmes... :O) !
Par contre, si vous avez prévu par exemple qu'à la fin d'un jeu, un nouveau jeu est rajouté au set, vous pouvez tester que la taille du tableau de jeux games de la classe Set s'incrémente. En effet, cette fois-ci, vous ne testez pas juste l'ajout d'un élément dans un tableau, mais la logique qui se déroule à la fin d'un jeu. C'est un test utile, car il peut échouer si votre code est mauvais ou réussir s'il est correct !
En résumé
Dans le MVC, nous allons tester uniquement le modèle.
On cherche à tester uniquement l'interface d'une classe sans s'occuper de l'implémentation de cette dernière.
Pour tester, il faut un code testable. Les tests vous incitent à créer des classes découplées à responsabilité unique.
Un test est utile s'il peut échouer et réussir.
Dans le prochain chapitre, vous allez créer votre tout premier test !
