Nous avons testé deux classes pour le moment : Game et Set. C'est bien, mais nous n'allons pas nous arrêter en si bon chemin ! On a dit qu'on allait tester tout le modèle !
[Suspens insoutenable...]
Eh oui ! Bien sûr il existe ! On appelle cela le code coverage. Cet outil regarde quelle partie du code est couverte par les tests. Pour cela, il regarde tout simplement quelles sont les lignes de code qui sont exécutées lorsqu'on lance les tests. Celles qui sont exécutées sont couvertes par les tests, les autres ne le sont pas.
Installer le code coverage
Pour installer le code coverage, nous allons devoir éditer le schéma de notre application (scheme en anglais).
Pour cela, cliquez sur le nom de l'application en haut à gauche.
Dans le menu déroulant qui s'affiche, cliquez sur Edit Scheme....
Une pop-up apparaît et vous présente le schéma :
Mais c'est quoi ce schéma ?
Ne vous inquiétez pas, je vais en parler. Un schéma, c'est la séquence des actions que peut subir votre code. Il y en a 6 qui sont données sur la gauche de la pop-up. Pour l'instant, vous en connaissez 3 :
Build : compile votre code (cmd + b).
Run : exécute votre code, une fois celui-ci compilé (cmd + r).
Test : lance vos tests (cmd + u).
Pour l'instant, nous allons cliquer sur la phase de Test (comme la flèche rouge l'indique). Et dans cette interface, nous allons cocher la case Gather coverage data. Puis vous pouvez cliquer sur Close.
Maintenant, lorsque vous allez lancer vos tests, Xcode va collecter les données de couverture et vous donner les lignes de code qui ont été exécutées pendant les tests.
Inspecter la couverture de code
Pour inspecter la couverture du code, il vous faut commencer par lancer les tests (rappel : cmd + u).
Une fois que vos tests ont réussi, vous pouvez aller dans le navigateur de rapports :
En sélectionnant Test, vous arrivez sur la page de rapport des tests où vous pouvez voir tous les tests, s'ils ont réussi ou non, les trier selon certains critères.
Ensuite, on cliquant dessous sur Coverage, vous pouvez accéder à la couverture en pourcentage de chaque fichier, et même de chaque fonction. Ainsi vous pouvez visualiser très simplement où vos tests ne passent pas.
Et comme vous pouvez le voir, nos classes Game et Set sont testées à 100% ! Nous avons fait du bon travail ! Pour avoir plus de détail, vous pouvez afficher le fichier Game.swift et les informations de coverage sont maintenant disponibles à droite du fichier.
En revanche, si on prend le fichier Match.swift, il contient plein de trous !
Toutes les lignes rouges sur la droite avec un zéro ne sont pas testées ! Nous allons y remédier.
La grande question
Juste avant de boucher les trous, je voudrais aborder la grande question de la couverture des tests :
Quel pourcentage de couverture dois-je atteindre ? 100 % ? 90 % ? 50 % ?
Et la réponse est : ce n'est pas une question de pourcentage, mais de stratégie.
Par exemple, lorsque vous travaillez avec un modèle MVC, je vous suggère de faire du 100 % de couverture pour votre modèle. Le reste est trop difficile à tester, comme nous en avons déjà parlé. Donc sur le total, je n'ai aucune idée du pourcentage de couverture que cela va donner pour votre code.
L'essentiel, c'est de choisir une stratégie et de s'y tenir ! Le pourcentage n'importe pas. C'est juste un outil.
Boucher les trous
Allez on bouche les trous ! Il me faut 100 % sur la classe Match !
Je suis ravi que vous soyez aussi enthousiastes ! Mais attention, ce n'est pas parce qu'on a appris à inspecter la couverture en tests de notre code qu'il faut oublier ce qu'on a appris avant !
On teste en s'intéressant toujours uniquement à l'interface de notre classe, on ne s'occupe pas des méthodes privées. La couverture est un outil qu'on utilise après avoir rédigé les tests, mais pas avant. Les tests ne doivent pas être motivés par la couverture, mais par les usages de la classe. La couverture n'intervient qu'à la fin en vérification.
En résumé, on est pas là pour boucher des trous, mais pour vérifier que notre classe fait bien ce qu'on lui demande !
Donc la première chose à faire, c'est de regarder l'interface de notre classe Match !
À partir de cette interface, nous pouvons déduire qu'il y a 4 propriétés calculées à tester : winner, isOver, scores, currentGame et une méthode pointEnded(wonBy player: Player).
C'est cette trame qui va vous permettre de faire vos premiers tests. Ensuite on peut anticiper que la méthode pointEnded est assez grosse, donc il va falloir peut-être créer plusieurs tests pour la couvrir complètement. En effet, on ne va pas traiter un point lambda de la même manière qu'une balle de jeu, de set ou de match !
Exercice
Testez intégralement la classe Match. Partez de la trame que nous venons de définir et atteignez une couverture à 100 % de la classe.
Pensez à factoriser dès que vous constatez une répétition dans votre code ! Vos tests doivent toujours rester lisibles !
Une fois l'exercice terminé, vous pouvez consulter la correction ici.
En résumé
Vous pouvez installer le code coverage en éditant le schéma de votre application dans la phase de test.
Le code coverage permet de visualiser les zones de votre code qui ne sont pas couvertes par un test.
Il ne faut pas chercher à atteindre les 100 % de couverture à tout prix ! Il faut surtout choisir une stratégie de test et s'y tenir ! Le code coverage est un outil bien pratique, mais pas une direction à suivre !
Les tests ne doivent pas être motivés par la couverture, mais par les usages de la classe.
Dans la prochaine partie, nous allons repenser intégralement votre approche de la programmation. Vous allez à apprendre à rédiger du code infaillible ! Et je n'exagère même pas. J'espère que vous avez aussi hâte que moi d'y être ! À tout de suite !
