• 12 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

Ce cours est en vidéo.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

J'ai tout compris !

Mis à jour le 29/05/2019

Que tester et quand le tester ?

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Je vous ai montré comment tester unitairement du code assez simple. Bien évidemment, cela risque de se corser un peu dans le futur en fonction des situations auxquelles vous serez confrontés.

N'hésitez pas à faire un tour sur la documentation officielle de la librairie PHPUnit pour avoir une meilleure idée de tout ce qu'il est possible de faire. Cette librairie est très riche et permet de répondre à bon nombre de problématiques.

Tout cela étant dit, je souhaite attirer votre attention sur un point important… vous apprendre à savoir quoi tester et quand le tester.

Que faut-il tester ?

Il n'est pas rare que l'on nous demande une couverture de code de 100%. Et pourtant, la couverture de code n'est pas la règle absolue à suivre ! La couverture de code n'est qu'une métrique qui montre le code qui a été exécuté par vos tests.

Prenons un exemple avec le code suivant :

Premier chemin à tester
Premier chemin à tester
Deuxième chemin à tester
Deuxième chemin à tester
Troisième chemin à tester
Troisième chemin à tester

Il existe plusieurs manières de tester une ligne de code donnée. Par ailleurs, un test doit aussi pouvoir permettre de détecter les cas limites qui n'auraient pas été vus lors de l'élaboration des spécifications.

Il est important de concentrer vos efforts dans l'écriture de tests couvrants le code dit "critique" de votre application.

Je prends comme exemple une application e-commerce. Ce qui fait le succès de ce type de site, c'est l'affichage des produits et la possibilité de commander ceux-ci. Dans le cadre de tests unitaires, il faudrait donc prendre soin de faire en sorte que la description de produit comporte assez de caractères, ou qu'ils aient un titre bien formalisé, ou encore que la méthode en charge du calcul du total d'une commande fasse correctement son travail.

Retenez donc qu'il est important de tester est ce qui est important pour le business de l'application. Ne visez pas le 100% de couverture, visez le maximum de cas d'utilisation du code.

Quand faut-il tester ?

L'une des problématiques récurrentes dans l'écriture de tests est le temps à passer sur l'écriture de ceux-ci. Étant donné qu'il s'agit de code qui n'est pas directement exploitable par les utilisateurs de l'application, il est assez simple d'arriver à se dire, pris par les délais, que finalement, il n'est pas utile de les écrire.

Il vous arrivera également de passer par un sentiment de grande difficulté lorsque vous prendrez peut-être plus de temps à écrire un test qu'à écrire du code lié au fonctionnement même de votre application. :'(

Écrire des tests demande une grande rigueur avec vous-même : en effet, il faut prendre le temps de lister ce qu'il faut tester, écrire ces tests et surtout les maintenir à jour. Ce n'est pas une mince affaire !

Il est primordial d'intégrer ce temps d'écriture de tests dans vos estimations de temps (ou de complexité). Au même titre que l'écriture de code fonctionnel, les tests doivent faire partie du développement de l'application. Tout comme le temps que vous prenez à ouvrir votre navigateur pour lancer votre application web et la tester à la main, c'est du temps qu'il est absolument nécessaire de prendre !

Vous pouvez écrire vos tests à différents moments au cours de votre cycle projet :

  • avant d'écrire votre code fonctionnel ;

  • après avoir écrit votre code fonctionnel ;

  • lorsqu'un bug est détecté.

Avant d'écrire le code

On parle de Test Driven Development (TDD). Il s'agit de développement mené par les tests. Il y a 3 étapes à respecter :

  1. Écrire le test.

  2. Lancer le test et vérifier qu'il échoue.

  3. Écrire le code fonctionnel.

  4. Lancer le test et vérifier qu'il est ok.

Cette méthode est très rassurante étant donné qu'elle demande à ce que le test passe en premier, donc plus d'inquiétude quant à l'idée d'abandonner les tests ! :D

Néanmoins, il faut a priori savoir ce que vous allez développer en matière de méthode(s) et classe(s)… Et soyons honnête, ce n'est pas toujours très clair avant de s'y mettre vraiment. C'est un pli à prendre, plus vous pratiquerez, plus ce sera simple. ;)

Après avoir écrit le code

C'est ce qui est le plus communément fait. Il s'agit simplement de reprendre le code développé jusque-là et le tester afin de s'assurer que celui-ci fonctionne comme prévu.

Le danger ici est de se laisser aller à l'idée que finalement  écrire un (ou plusieurs) test(s) n'est pas nécessaire, par manque de temps ou par excès de confiance.

Lorsqu'un bug est détecté

 Plutôt que de se lancer tête baissée dans la correction du problème remonté, il faut :

  1. Le reproduire avec un test.

  2. S'assurer que le test échoue.

  3. Écrire le code pour le corriger.

  4. S'assurer que le test passe correctement.

Cette manière de faire permet d'accumuler une batterie de tests couvrant bon nombre de cas, au fur et à mesure des anomalies rencontrées. Cela permet également de s'assurer que, d'une anomalie à l'autre, la correction apportée n'introduit pas de régression.

 

Ces trois solutions peuvent être adoptées tout au long du projet ! Le plus important est d'être à l'aise et surtout de ne pas abandonner l'écriture de tests !

Il est également intéressant de se mettre à l'écriture de tests pour une application dont on ne connaît pas le code : en effet, un test unitaire nécessite de connaître le code à tester. Cela force donc à lire ce code et à le comprendre. :soleil:

 

Rendez-vous au prochain chapitre pour découvrir le monde merveilleux de l'intégration continue.

Exemple de certificat de réussite
Exemple de certificat de réussite