Close

Quels tests pour un projet web ?

Les tests logiciels sont un élément très important que tout développeur devrait maîtriser. Malheureusement, la pression de la hiérarchie à tenir les délais de livraisons et à développer toujours plus vite n’aidant pas, les tests sont souvent relayés à « quand on aura le temps », soit à jamais ! Et une fois qu’on arrive à se dégager du temps (ou bien quand tout est tellement bancal que les tests deviennent une nécessité absolue), on ne sait plus par où commencer pour mettre en place ces fameux tests.

Qu’est-ce que les tests logiciels ?

Ce que j’appelle tests logiciels, ce sont tous les tests écrits par les développeurs eux-mêmes, qui permettent de s’assurer que le code fait bien ce qu’il est censé faire. Ces tests ont l’avantage d’être automatisés (il suffit d’exécuter une ligne de commande pour les lancer) et rapides à exécuter. Ils permettent au développeur de s’assurer, à tout moment, que tout fonctionne bien.

Quels sont les avantages ?

Voici selon moi les deux principaux avantages (il y en a plein d’autres) :

Tout d’abord, chaque nouvelle fonctionnalité (ou nouveau bug) doit avoir un (ou des) test(s) associé(s). Cela assure au développeur que le code fait bien ce pourquoi il a été écrit.

Ensuite, si les tests sont complets, à chaque nouveau développement ou à la correction d’un bug, ils permettent d’assurer au développeur que les lignes de code qu’il vient d’ajouter ou de modifier n’ont pas changé le fonctionnement du programme, et donc n’ont pas créé de nouveau bugs. C’est ce qu’on appelle la non régression, et c’est très pratique.

Quels sont les différents types de tests ?

Le test unitaire (TU)

C’est le plus connus (et le moins bien utilisé).

Son but est de tester une classe, indépendamment des autres classes. Pour cela, il est nécessaire de simuler (à l’aide de Stub ou de Mock) toutes les autres unités qui sont en relation avec la classe à tester. Il est donc parfois long de tester une classe de façon exhaustive avec des TU.

Le test de comportement (TC), mon préféré

Contrairement aux TU, les TC s’intéressent à tout le système. Le but est de tester le programme dans son ensemble pour valider le comportement global, à partir du point d’entrée (le contrôleur) jusqu’à la base de données. Les scénarios de tests sont plus complets, ils cherchent à reproduire un cas d’utilisation concret. Pour cela, il est nécessaire d’utiliser une base de données de tests, dans laquelle on ajoute des données qui serviront lors du TC.

Les TC sont au cœur du principe du BDD (Behavior Driven Development).

Les autres tests

Je ne développerai pas ici les différents autres tests logiciels qui existent. Dans le milieu du web les deux principaux tests sont selon moi les TU et les TC. Les autres (tests d’intégrations, tests de validations, tests de charge, etc) ne sont bien évidement pas inutiles, mais trop couteux dans le cadre d’un projet web. Si les équipes de dév (et leurs mangeurs) arrivent à dégager assez de temps pour faire des TU et des TC,cela serait déjà un grand pas en avant.

Comment tester ?

C’est là où ça se gâte. Chaque développeur a sa propre approche et sa propre philosophie pour savoir quoi et comment tester. Voici ma façon de faire :

Les TU sont parfois assez couteux à mettre en place et difficiles à maintenir. Selon moi, toutes les classes ne sont pas bonnes à être testées avec des TU. En effet, il faut réserver les TU pour les classes qui contiennent des algorithmes, c’est à dire les classes qui font des choix en fonction de leurs données d’entrée. Inutile par exemple de tester les contrôleurs et les repository. C’est pourquoi je pense qu’il faut limiter leur utilisation au strict nécessaire.

Les TC doivent être les tests qui représentent des cas d’utilisation concrets. Par exemple, créer un nouvel utilisateur ou emprunter un livre à la bibliothèque. Ils ont le désavantage d’être longs à exécuter, il faut donc ne pas en abuser. Par contre ils ont l’énorme avantage de tester des vrais cas d’utilisation du logiciel, et d’être écrits en français (et non en code que seul un dév peut lire), ils sont donc très lisibles et faciles à faire évoluer quand le besoin du client change.

Qu’est-ce qu’un QA ? Que teste-il ?

Un jour, j’ai proposé à mon directeur R&D de faire une présentation du BDD afin d’essayer de commencer à mettre en place quelques tests, il m’a répondu : « Pourquoi faire ? On a un responsable QA qui arrive dans 2 mois ! » (true story). Et oui, les rôles de chacun ne sont pas toujours bien définis, essayons d’y voir plus clair.

Un QA (Quality Assurance) est une personne chargée de tester l’application d’un point de vue utilisateur afin de valider que tout fonctionne bien et que les développements correspondent bien à la demande du client. Si oui, il donne le feu vert pour mettre en production. Alors forcément, il est là pour aller chercher la petite bête (un bouton pas bien aligné, des temps de réponse trop longs, etc), et c’est parfois un peu tendu entre les développeurs et lui. Mais il faut bien l’avouer, c’est quand même très rassurant de savoir que quelqu’un va tester de fond en comble l’application avant chaque mise en prod.

C’est parfois à cause de lui que les développeurs se laissent un peu aller en se disant « je ferai les tests quand j’aurai le temps » (jamais) ou bien « de toute façon le QA va tout tester ». Oui mais voilà, ça marche au début quand les applications sont petites. Mais dès que ça commence à grossir, on arrive rapidement à des situations où le moindre bug corrigé en crée des nouveaux. C’est à ce momentlà qu’on ne s’en sort plus et que les projets n’avancent plus !

Pourquoi les tests passent souvent après tout le reste ?

Malheureusement, les tests logiciels sont (à tort) assez peu enseignés dans nos écoles/universités, ce qui explique certainement le manque d’intérêt qu’ont les développeurs à les mettre en place. De plus, le fait d’allouer 20 à 30% de son temps à écrire des tests est souvent mal vu par les mangeurs, qui ne comprennent pas l’intérêt que peut avoir un logiciel bien testé. Dernier point, le manque d’implication des développeurs, qui considèrent l’écriture des tests comme une tache beaucoup moins intéressante que l’écriture du code source.

Conclusion

Pour résumer, dans un projet orienté web où les temps de développement doivent être les plus courts possible, les tests sont souvent relayés en seconde zone. Pour bien faire les choses, l’idéalserait d’écrire des TU pour les classes les plus importantes du logiciel, et des TC pour s’assurer que les fonctionnalités globales continuent de fonctionner. Ajouter à cela une équipe QA, et votre logiciel gagnera en qualité et en fiabilité.

Même si les tests prennent du temps à développeur et à maintenir, à terme ce n’est pas du temps perdu.

Leave a Reply

Your email address will not be published. Required fields are marked *